Who has the fastest F1 website in 2021? Part 3

Posted 29 March 2021

I once spent an hour creating an F1 lights-out reaction test which went viral and was even played by F1 drivers. That sounds like a brag, and it kinda is, but now whenever I pour days or even weeks of work into something, it just seems so inefficient compared to that time I spent an hour on something that went big. Wait! You're not my therapist! Let's look at another F1 website…

This is part 3 in a multi-part series looking at the loading performance of F1 websites. Not interested in F1? It shouldn't matter. This is just a performance review of 10 recently-built/updated sites that have broadly the same goal, but are built by different teams, and have different performance issues.

Red Bull

Link: Red Bull Racing Honda
First run: 6.7s (raw results)
Second run: 1.9s (raw results)
Total: 8.6s
2019 total: 15.8s (2021 site is 7.2s faster)

Now we're talking! This is a graphically rich, engaging site, and the performance is pretty good! In fact, it's significantly faster than its 2019 site. But there's still room for improvement.

Possible improvements

3 second delay to content-render caused by unnecessary inlining. Covered in detail below.
10 second delay to main image caused by a JavaScript responsive images implementation, like we saw in part 2. These should be real responsive images.
Additional 2 second delay to main image caused by an extra connection. This problem is covered in part 1, but the solution here is just to move the images to the same server as the page.
Additional 2 second delay to main image caused by poor optimisation. Covered in detail below.
40 second delay to key image caused by loading it with JavaScript. Covered in detail below.
Additional 30 second delay to that image caused by poor optimisation. Covered in detail below.
2 second delay to fonts caused by extra connection. Again, this is covered in part 1, but the solution here is just to move the fonts to the same server.
40+ second delay to content-blocking cookie modal caused by… a number of things, covered in part 1.

Remember these delays overlap in some cases.

Issue: Unnecessary inlining

Here's the first bit of the timeline:

The page renders around the 6s mark, which is while the HTML is still downloading. Browsers can stream HTML and render it while it's downloading; it's a great feature of parsed-HTML that many sites don't get the benefit of due to blocking resources. Because the page renders with that one resource, we know there are no blocking resources. This suggests the CSS is inlined, and from looking at the source, yep, it is.

Inlining avoids request/response overhead, which is great for render-blocking resources. But also, since it's part of the page, you can tailor the inlining for that page.

However, that doesn't seem to be what's happening here. Here's what I see in Chrome DevTools' coverage panel:

The code in the page is 79.5% unused, which amounts to over 600kB. Compare this to the coverage on Squoosh:

…where we used inline content just for the CSS and script needed for the first interaction. The first row there is a non-blocking resource, where coverage doesn't matter so much, but the bottom row is the page, where only 7kB is unused. You can also click on these lines which takes you to a code view of used and unused code:

Anyway, we aren't here to talk about Squoosh. Around three seconds could be shaved off time-to-content on the Red Bull site by making the inlined code tailored to what the page needs for that content-render. The rest can be loaded via external resources.

Issue: Large primary image

It's great to see them using WebP, but the quality is just set too high. Yes, some detail is lost in the compressed versions, but remember this image has text over the top, and another image over the top.

Actually, let's talk about that image…

Issue: Large overlay image

This image sits over the top of the main carousel, and it's a great part of the design. Again, they're using WebP, but maybe not with the right settings. But even with optimised settings, the WebP is still big.

When WebP was created, they designed the alpha channel around things like logos, and things cut-out of photos. In these cases the alpha channel is dominated by large areas of the same value:

Because of this, they used the WebP lossless mode for the alpha channel, even if the colour data is using the lossy mode. This works well in general, except in cases like this:

…where the alpha channel is frequently changing. This is something a lossy codec handles much better. AVIF can perform lossy encoding of all channels, including the alpha channel, so it performs an order of magnitude better than WebP in this case.

For cases where you need genuine lossless images, WebP is a better choice. AVIF supports lossless encoding, but the sizes are usually around 2x of WebP.

Issue: Overlay image loaded with JavaScript

That overlay image doesn't start loading until the user has been on the site for over 50 seconds, which almost certainly means something is blocking it. The 'initiator' column in the network panel didn't help this time, so I searched the source for the image URL, and found it in a blob of JSON at the end of the document. If it's JSON, that means JavaScript is handling the load of that image in some way.

I would switch this for an <img> so responsive images could be used to select the best format for the job. This will trigger the download much earlier.

There's a risk that the massive WebP version could end up taking bandwidth from more important things. If this happened, I'd use preloads to bump the priority of more-important content.

Issue: Large inlined blurry image

The performance issues the Red Bull site has with images are pretty well disguised using a low-quality inlined image, but with a blur(7px) effect. Unfortunately the image they use isn't an accurate preview of the image being loaded, as it's cropped incorrectly, so there's a jump when the final version loads. However, I really like this method, as it provides more structure than something like a BlurHash, but it does use more bytes.

Their blurred images are 6kB each, which is quite a lot to inline, especially when the well-optimised mobile version of the image is only around twice the size. 150x150 is also an odd choice for creating a tiny JPEG, since JPEG is encoded in 8x8 blocks. If you're interested in details like this, I gave a talk on how JPEG works.

Anyway, I had a play around to see what I could do with 1kB:

JPEG suffers from heavy blocking artefacts, so I had to increase the blur to hide it. WebP is much better, so I was able to go with a higher resolution and less blur.

If you're going to create super-small images like this, you'll want to disable "chroma subsampling" in the codec. Subsampling uses lower-resolution colour data, which usually works well for compression, but it's really noticeable at small sizes like this.

Squoosh lets you disable subsampling for JPEG and AVIF, but it can't be disabled for WebP, as the format doesn't support it. To work around this, the WebP encoder has a "sharp RGB to YUV" option which tries to limit the impact of subsampling at the cost of some colour bleeding. I used that option above.

AVIF does ok here, displaying less noise than WebP, but since the AVIF format has around 300B of headers, we don't really see the usual AVIF 'magic' that we see with other images.

When it comes to an inline preview like this, you can only pick one image size and format. I'd go for the WebP, since it has decent quality and pretty good support.