Building for speed

A fast website doesn’t just provide a good experience, though that’s certainly important, it also ensures as many people as possible can access it. Users are not the only ones that will look down on a slow website, search engines demote or omit your site from search results if fall bellow certain performance metrics.

Here are the steps I took to ensure the whatever the conditions were this site would be as fast as possible:

1. This site is static, meaning that all of the pages are pre-rendered on the server and then served directly. Most websites have many back-and-forth requests with a server before presenting a page; this one does not, which speeds things up considerably. Serving static content typically saves ~500ms of loading time.
2. I’m using a webfont for the headings, but the body text uses a font stack that leverages the viewer’s system’s default font, which does not need to be loaded from the server.
3. I am serving most of the images apart from the logo (which is a SVG) in optimised JPEG, which drastically reduces load times
4. I followed a series of patterns for my CSS styles to reduce the file size¹, which again reduces download times.

Absolute vs. perceived performance

The changes above impact the page load time/size, which correlates to the absolute page speed. But that’s not all that matters. Another key component of speed is the perceived performance . This affects how fast your site feels.

When loading the site on 3G there’s a full 1.5 seconds between the initial content displaying and the webfont displaying. Further still, because I reference the webfont directly in CSS, via @font-face, there’s a FOIT making the headings completely unreadable until the webfont has finished loading.

Preventing a Flash of Invisible Text (FOIT)

I’m going to use FontFaceObserver to instead only apply the webfont to headings after it is loaded. While it is loading, they’ll use the same font stack as the body text, changing the FOIT into a FOUT. In some scenarios, this can provide a poor experience just like a FOIT, but it has a few advantages:

1. The body text is set in a font that doesn’t have to load at all, meaning it will display correctly immediately. So when the headings also use that font while the webfont loads, they’ll match the rest of the site.
2. The webfont I’ve chosen for the headings, has a very similar baseline & caps height, so change after the webfont loads is minimal.

With this approach, you can see how the headings now display for a brief moment using the same font as the rest of the text, and then switch to the webfont after it has finished loading.

By Damilola Payne