I’m sure your website is fast enough already and you don’t need any more performance tips. But if you are still here and interested in one more, let’s talk about early hints, which is a way for when the browser is loading your webpage, it can get started before the server has even responded.
The server can be busy. I’m sure it’ll send a really good response in 300 milliseconds, but the browser can get started on those critical assets like JS and cs. Css. Yeah, I can definitely Web. Yeah. Okay, let’s dive in.
Your page essentially is a list of assets you have to load, whether it be JavaScript, css, images, fonts, long list of stuff, and they typically fall two camps.
The critical stuff that has to happen like as quickly as possible, which will do lots of optimization over, and then the everything else, which will defer to the last minute, so it doesn’t affect page performance. Today we’re just talking about that critical stuff, stuff that we’re optimizing for, that we want to get started as quickly as possible.
Now, we have a few tricks in our book to try and speed that up, but all of them are pretty much dependent on the server having responded. So typically there’s a bit of a gap between the browser making a request for a certain page and the server then responding. You know, we’re talking about that Time to First Byte metric really, and the server think time.
Early hints provides a way of telling the browser some assets to load that it can get started on before the server is actually ready for its full response. And so you can imagine that makes you know far better use of time and can improve your page performance. Now, the way it does this is by specifying some of those in a HTTP header on your traditional response, which then either your Web server or more typically your CDN and CloudFlare particularly in this case can send those, that response.
So it sends two responses. In quick succession, it’ll send an initial 103 response with just this link header, which is a list of all of the assets that it knows that you will need, and then it will follow up with a full response when it has a second. Well, less than a second, hopefully. So that’s early hints.
Let’s dive in to get a little bit more details.
So if I swap over to a couple of different things, I’m gonna show you first here. This is a curl request. So this is just a way of me requesting the page and I’m doing -I, which just tells me the headers. And you can see here requesting from our Space 48 Apps demo site. We have an initial response, which is a 103 response, and it has a, just a single link header with a list of all of the assets that we are telling the browser “it would be good to preload this stuff so you can get started a little bit quicker”. And then straightaway after we actually get the full response, we’re only showing the headers here . Now, what this means, is if I then hop over to a waterfall chart, I’ve got two waterfall charts here.
These are tests before and after. Adding these early hints. We have at the top here, we have the kind of before with a request to demo.space48apps.com. And you can see the blue bit is the kind of the waiting for the server response. We’ve connected the server, we’re waiting for the response in the slightly darker blue bit is actually transferring the response back to us.
So there’s a good, you know, 400 milliseconds there of waiting time. And you see, we don’t actually make the first request for a page asset for the Google fonts or the CSS or JavaScript until just after a second. i.e. just after we started reading the page. So that kind of sucks. So we add these link headers, and if we look at the second half of the page, it’s the same page again, but we’re now sending these 103 responses earlier on, and you can see that the, the font and the CSS file starts to load between 0.7 and 0.8 seconds.
You can see that this is about 240 and 250 milliseconds earlier. And really like the whole page load is then brought forward by that point. Some of the other things to, to pick out on the graph, like we’ve got the green lines on the vertical green lines, top and bottom, they are also faster and that’s when the page starts to render.
We have the dotted darker green line that is also faster. That is the largest contentful paint. The yellow is DOM loaded and the pink is DOM interactive. So everything is slightly faster when we’ve got early hints because our first requests can get going a bit quicker.
Now BigCommerce added native support this in collaboration with their CDN provider that they use which is CloudFlare.
So in order to support this in your theme, you would need to add a, this tag here, which is a resource hint preload as script into your handlebars template. And you are saying that, and this is out of the box in Cornerstone. So this is what Cornerstone as of 6.7 will look like, but you can also add this to any of your own JavaScript files that you add as well.
So that’s you telling BigCommerce what to add as a link header. So those are the link headers, which we can also see start to come back in our responses. And CloudFlare, as a CDN in between can then look at this, read this and cache this for further people.
It’s not something they probably cache for very long, but it’s something that they can then send the next time they get a request from a user, they can send a 103 response straight away while asynchronously, they’re sending a request to BigCommerce for the actual page load. So that’s how the speed-up happens.
Kind of going back to our chart, we can see that if it’s about 250 milliseconds and about four-second page load in this sort of lab environment on a phone and 4G, we are getting about 5% speedup. 📍 So there’s no silver bullets in the game of performance, but still
I’d say that was pretty good going. Any questions or thoughts, please, give me a shout in the comments. We’d love to chat with you if you’re on the BigCommerceDevs slack to chat through this change.
Otherwise @bobbyshaw on twitter.
