When it comes to site speed, there's something known as the critical path. You'll probably see references to it in tools like Google's PageSpeed Insights when it recommends things like "avoid chaining critical requests".
It sounds complex and technical, but I promise you - it's not as complicated as it first seems.
What is the critical path?
When it comes to site speed, for most sites the first and biggest aim is to download and render the contents of the page above-the-fold as fast as possible.
There are usually a number of resources that are required to do that, and these are known as critical resources or critical requests. For most sites, these would be:
- the HTML document itself
- any CSS files in the
<head> - any synchronous JavaScript in the
<head> - any custom fonts
Because these files are all required to start rendering the page, they are on the critical path. And if the goal is to render the above-the-fold contents of the page as fast as possible, and these critical resources are required to do that - then it makes sense to focus on getting the browser to prioritise downloading these files first.
Which resources is the browser prioritising for my site?
If you want to know which order your resources are being downloaded in, you can use a tool like Chrome DevTools or WebPageTest to find out. Both tools can show you a waterfall chart, showing a list of resources that the browser downloaded, in the order that it downloaded them. Here's what it looks like for the homepage of tryblackbird.com over a 4G connection:
This shows a request for the HTML document first, followed by the CSS, and then a font file. At this point, the browser has everything it needs to start rendering. It'll continue downloading the asynchronous JavaScript and images from this point on, but it's now render to start painting pixels to the screen.
WebPageTest is great for this - try it on a page on your site and see which resources it loads first. You want the first few resources that it loads to be the ones that are required for your page to render the above-the-fold content.
For most sites, the first resource you want to see get requested is the CSS.
Speeding up CSS
For the majority of ecommerce sites, getting the critical CSS to load quickly is the most important thing when it comes to rendering the page quickly. This is because CSS in the <head> is a render-blocking resource: browsers won't start rendering the page until it has downloaded and parsed CSS found in the <head>.
For tryblackbird.com, we speed up delivery of our CSS in a few different ways. Firstly - we try to keep the file size as small as possible. There's still improvements that we can make here, but when compressed, it's less than 10kB. We serve it using gzip, which means it's compressed when it's sent over the network - so the user doesn't have to download the full uncompressed file. We also make it the first resource in the <head> to help make sure the browser downloads it first.
We also go a step further and make use of HTTP/2 server push to send our CSS file. Ordinarily, a browser will request the HTML document first, then it will start reading the HTML document that gets returned, see all the sub-resources, and send new requests for those. With server push, you can tell the server to send your CSS file (or any other file you want) along with the HTML document. In truth though, this is usually quite difficult to implement and has a pretty minimal impact.
For most ecommerce sites, you should focus on making your CSS as small as possible, ensuring that it's minified, compressed with a technique like gzip or brotli, and by making sure it's the first resource in the <head>.
Avoid synchronous JavaScript resources in the <head>
Synchronously loaded JavaScript is parser blocking. If the browser sees a synchronous <script> tag, it pauses parsing of the page and waits until the JavaScript has been downloaded and executed. If that synchronous JavaScript is in your <head>, then this will delay rendering, sometimes by a lot.
Often, JavaScript doesn't need to be synchronous like this. Things like marketing tracking tags can be loaded asynchronously, by adding the async attribute, like this:
<script src="script.js" async />This will take the JavaScript file off the critical path. Instead of being fetched and executed early on, it will still be fetched at the time of discovery - but it won't execute until later, and importantly it won't block the rest of the page from being parsed by the browser until it's downloaded.
Self-host your static assets
There might be times where you have to have synchronous JavaScript in the <head>. jQuery is a good example. It's often used for layout, and often results in things breaking if it loads in asynchronously. So if it's synchronous and loaded in the <head>, then it's on the critical path.
But it's also really common for sites to host jQuery from a shared hosting provider, like googleapis.com or jsdelivr.net.
Using shared hosting libraries like this makes it easy to get up and running when building a site, but they come with a performance overhead. When the browser starts loading a page, and then has to fetch a file from a different domain, then it needs to make an SSL connection to that domain first. This can easily take several hundred milliseconds - and even seconds on a slow connection.
There's a common belief that using a shared hosted file like this can be faster because a user might already have that file in their cache, if they've been to another site that also uses that Google hosted jQuery file. That might have once been the case, but Safari doesn't support it for privacy reasons, and support for it is also soon to be removed in Chrome, meaning there won't be a shared caching benefit anymore.
Self-host your font files
Fonts can also be considered critical resources for most ecommerce sites, because you want them to load in as quickly as possible so that the page looks correct, and so you minimise the chance of seeing a jarring flash of unstyled text.
If you think of font files as critical resources, then you'd benefit from self-hosting those too, instead of relying on a platform like Google Fonts. While Google Fonts is great for getting up and running, and even though it does some very smart things to ensure it serves small file sizes, it will always come with the same third-party connection overhead.
We wrote about self-hosting Google Fonts, and discovered that doing so improved our Largest Contentful Paint by 1.3 seconds on a 3G connection. For ecommerce retailers, a 1.3 second LCP improvement can result in a very noticeable improvement in conversion rate.
Keep your critical path as short as possible
Ultimately, the real lesson here is to try to limit the number of resources you have on your critical path.
Your critical resources - those resources needed for rendering to start - should be kept to a minimum, should be hosted on your own domain instead of a third-party, and should be as lightweight as possible.