Fast-loading web pages have never been so important. According to a recent Nielsen study, the results are unambiguous: 40% of all visitors leave a website if they can’t properly interact with it within two seconds.
To kick things off, I’ll present a recommendation outlining a set of key metrics which go much further than the commonly known PageSpeed Insights Score (PIS) from Google – because measuring web performance is so much more than just observing at a single number. Granted, Google “upgrades” their tool frequently, but nevertheless, there’s a broad variety out there and I’ll give you my suggestions on what’s important to measure, and how to do it. Contemporary websites should utilise the measurement of paint timings and pay special attention to the “time to first meaningful paint” event which marks the point when the most significant above the fold layout change has occurred, and when the most important element is visible:
Think YouTube: when you’re visiting the site, all you really care about is the video – this element needs to be there super-fast; elements like navigation, logo, related videos or comments can follow, but the video is your hero element and needs to be there fast! Measuring paint timings ties in nicely with a concept known as critical rendering path optimisation – something Google is currently discussing a lot. Essentially, this is commonly referred to as the initial view (which is essential for any user since it’s the section of the website they see on their screen immediately), followed by all the below the fold content (which isn’t critical as you’d have to scroll down to see it) as illustrated here:
Generally speaking, a fast-loading initial view has a direct impact on the perceived performance of your website. To implement this, you need to turn off as many render blocking elements as possible (such as JavaScript or CSS), otherwise the browser will have to wait for each of these files to return before continuing to render.
So, from a CSS loading perspective, this could look something like this:
To speed up your CSS delivery as much as possible, I’d recommend undertaking the following steps:
- Perform an audit and clean up (i.e. de-duplication, get rid of unused styles, etc.) and afterwards, split your CSS into two parts: one for the “initial view” and the second part for “below the fold”.
- Use Critical (which is free) to help identify, as well as generate, the critically required CSS info.
- Inline the previously generated CSS for the initial view (yes, inline!).
- Use rel=“preload“ and “loadCSS” to asynchronously load below the fold / site-wide CSS (a noscript tag will provide fallback for clients without JavaScript enabled).
By the way, there is a good reason why Google is inlining their entire CSS (on their search result pages): it’s way faster than making HTTP requests!
I’ll be covering this and lots more at inOrbit 2019 – I’m looking forward to seeing you there!