100 mph

Speed is important. We know this, and there are a few ways to gauge how fast your website is. These kind of measures, while inexact, can be more useful than uncontextualised questions like how many visitors did you get last month? Of course, we often report on the mainly meaningless.

Have some fun and enter a few addresses into Google PageSpeed Insights (pagespeed!; so quick the words elide). Some websites will score less than 40/100. Some don’t even configure the viewport.

Report on your score instead of some broadsword notion of SEO; it’s just as easy and will tell us a bit more about how well we’re doing, and what we need to keep an eye on. Yes, we may wonder how we earn a 63 as opposed to a 54, but we learn something about the experience of using a website on a crappy mobile phone connection.

Peer through the veil and beyond flashy graphics, animations and general bedazzle. How long does it take to do something and say goodbye to your website?

Improve your PageSpeed score

I cheat. I serve flat files, no javascript, less than 10k of CSS; not even a web font. I should score well:

My PageSpeed Insights score

Obviously, not everyone can forego javascript, images and webfonts, but there a few things I’ve done that you could apply to any site (I’ll assume you’re configuring the viewport):

Inline your CSS

Each file call incurs an overhead of 14k of data regardless of the actual file size. So, if you’ve got less than 14k of CSS dump it in the head and earn yourself 9 PageInsight points. You won’t even have to bother whether it’s critical or non-critical CSS.

If you’ve got more than 14k try to inline the bits Google considers ‘critical’. In theory, this is simply the ‘above the fold’ content and associated assets, but that’s obviously hard to define over a range of devices. (Try Inlining critical CSS for better web performance for a guide.)

Use flat HTML

Obvious this, but a site built on Jekyll will, under otherwise equal conditions, always be faster than something built on a database, regardless of what you’re doing under the server’s hood.

Caching will help, though. Your mileage may vary, but using WP Rocket (in our experience the best WordPress caching plugin) gained us a whopping 43 points on the work production site over the cache less staging server.

Use a well-configured server (or configure it yourself)

Google take an aggressive attitude to squeezing as much performance out of assets and caching as possible. This site is hosted by Github Pages and, as such, enjoys a CDN and CSS, HTML and javascript minimising with zero configuration.

Serve web fonts asynchronously with javascript and lazy load images

PageSpeed Insights will penalise any assets that stop the critical part of the page rendering.

The most common offenders are web fonts, which are easy to serve asynchronously. Instead of copying the link code from Google and pasting it into your website’s head, choose the javascript option. In Typekit, you’ll find the webfont loading javascript under the ‘Advanced’ tab in your kit settings.

This means your page will render before the webfont loads, which can result in a flash of unstyled text. However, this is preferable to the page hanging sans text.

Some servers will lazy load images for you (Netlify’s, for example), other times a plugin will do the job (WP Rocket). Or you’ll have to set things up yourself.

Conclusion

It’s probably nigh on impossible to score 100 without reducing your site to a a bare shell. However, concentrating on speed will put a design on the right footing. That’s not to say you can’t make great looking sites that aren’t fast - it’ll just make sure they remain fast.