On optimising Website loading times
I have to admit I was nerd-sniped this afternoon by Website loading times. It all started with a random find on an old blog post that lead me to the Glyphhanger Project, that internally uses fonttools, that in turn lead me to redo almost all my publicly facing webpages. Those always have been deliberately kept lightweight, partly to keep things simple for me, partly to improve loading and rendering times, and also somewhat inspired by the OG website 😉.
The placeholder landing page on this site’s TLD for instance is kept brutally minimal; if you overlook small intricacies such as the fade animation, the automatic dark-mode and the custom web-font.
Admittedly, there isn’t much to load and with everything being served statically there isn’t much waiting time for the server either; that it would be more surprising if the loading times were bad than not.
WebFonts, like Google Fonts and Adobe Fonts tend to rely on popular and thus often requested Fonts to be present in the caches, bringing down the total loading time for everybody. For me this meant having the visitor make an additional connection to Google to request the file including full DNS resolution, which I didn’t like.
Furthermore, they can weigh several hundred Kilobytes while improving the experience only marginally, which is why there are Content Blockers that now provide WebFont blocking. To cut down on this costs this blog does not use any custom Fonts at all, which might be the next big trend. But on the TLD landing page I wanted to have a consistent look for everybody, which is why I opted for Source Sans Pro as WebFont.
Reducing the WebFont down
Google Fonts provides optional parameters to further shrink down the Font file by requesting a single weight or script (using the
&subset=greek url parameter) or pass in an arbitrary text and retrieve a custom Font with the needed Glyphs (using
Modern Browsers provide the option to use the System Font if a comparable one is available and then swap it out with the WebFont one as soon as it is loaded. This can be enabled using the
&display=swap url parameter.
Because I didn’t like the additional request(s) for the WebFont, I manually embedded the
@font-face definition as inline style into the Markup, downloaded the WOFF reduced WOFF file and pointed to the local copy in the assets. This now weighed in a total of one additional Request of 7KB (200 Bytes for the CSS and 6840 Bytes for the “optimised” WOFF) to the same origin (full path contained in DNS cache).
Next I wanted to give the fonttools a try. Quickly installed it and its WOFF2 dependencies (
brotli) and then downloaded a copy of Source Sans Pro as TrueType font to have fresh base to start my experiment from.
Since I wanted to exclusively display the α character I, we can get rid of everything else; and the fonttools even provide a convenient way to do all this in a single command!
$ pyftsubset SourceSansPro-Regular.ttf --text=α --output-file=SourceSansPro-subset.woff2 --flavor=woff2
The resulting WOFF2 file now has a size of 1212 Bytes which is a decrease of 80% (total) and a new cost for the WebFont of the the same one additional Request of 1.4 KB to the same origin.
Happy with my WOFF optimisations I went on and looked at the seeger TLD landing page and checked the SVG file’s contents. The smiley was originally drawn on a post it by RAS5490 and traced in Vectornator using the Apple Pencil (highly recommended) and straight exported as SVG. This left additional information there that would help the App recreate their original Data Format from. I put it through SVGminify.
Original: 63605 Bytes After SVGminify: 45179 Bytes
SVGminify unfortunately didn’t remove the unnecessary Vectornator items. I had to manually remove them (making this a truly hand-crafted image) and put it through the minified again this time taking 44472 Bytes for a total decrease of -30%.
Google PageSpeed Insights is a valuable tool to improve see where you can improve your loading times. I for instance finally caught up on preload directives. I’m late to the party I know!
I am aware that sinking hours into making static sites render a few milliseconds faster is a waste of time. I did learn a few new things along the way though.