Who has the fastest F1 website in 2021? Part 6
This is part 6 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.
- Methodology & Alpha Tauri
- Alfa Romeo
- Red Bull
- Aston Martin
- ➡️ Ferrari
- …more coming soon…
The Ferrari site is my stand-out memory of the 2019 article. Their site was slow because of a 1.8MB blocking script, but 1.7MB of that was an inlined 2300x2300 PNG of a horse that was only ever displayed at 20x20. Unfortunately their 2021 site is slower, and this time it isn't down to one horse.
- 3 second delay to content render caused by unused CSS. Covered in detail below.
- 5 second delay to content render caused by other blocking script. Covered in detail below.
- 5 second delay to main image caused by render-blocking CSS & script. Important images should be part of the source, or preloaded.
- 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.
- 50+ second delay to content-blocking cookie modal caused by… a number of things, covered in part 1.
As always, some of these delays overlap.
Here's the top of the waterfall:
The green vertical line around the 11s mark is the first render, but you can see from the video above it's just a black screen. This is what I mean by 'manually-blocking' – the additional script isn't blocking the browser's parser or renderer, but the developers have chosen to show a black overlay until that script has loaded.
We already saw this in part 2, but in that case it was a small late-loading script. Here, the Ferrari folks have used
<link rel="preload"> to solve the priority problem, but the remaining problem is the sheer size of the script.
The bottom of the waterfall shows us the CPU usage on the device, and once that massive script lands, we get a bit of a car crash around the 32s mark. This will lock up anything that depends on the main thread for around 5 seconds. If we take a look at the coverage in Chrome DevTools:
Back to the waterfall:
Rows 22-25 are traditional render-blocking scripts in the
<head>. They're all on different servers, so they pay the cost of additional connections as I covered in part 1.
22, 24, and 25 appear to be trackers, which should use the
async attribute so they don't block rendering. The polyfill script on row 23 should use
defer too, but in this case it's just an empty script since the browser doesn't need any polyfills. They could avoid this pointless request by using the
nomodule trick we saw on the Aston Martin site.
Key issue: Unused render-blocking CSS
Back to the waterfall:
It causes around a second of delay around the 10 second mark. Looking at the coverage:
…almost all of that CSS is unnecessary.
Again, there isn't a quick fix here. That CSS just needs splitting up, so pages request only the CSS they need. A lot of web performance folks recommend inlining the CSS for a given page in a
<style> in the
<head>. "But what about caching??" is usually my response, but the more I see issues like this, the more I think they're right. A per-page targeted approach would avoid ending up with massive chunks of unused CSS like this.
Issue: Image optimisation
Y'know what? This might be the best site so far in this series in terms of image compression. Taking the main image:
Sure, AVIF gets you to 20% of the size, but we're not talking huge savings here in real terms. As usual, the AVIF is a lot smoother, but since this image sits behind text I felt I could go a little lower on the quality slider than I usually would.
Some images could be significantly smaller though:
A lot of the images on the Ferrari site aren't optimised for 2x screens. I don't think that matters so much for the previous image, since it's behind text, but the one above could do with some sharpness. The original image above is 480px wide, but the optimised versions are 720px (taken from a larger source), so in this case the optimised versions are also higher resolution.
How fast could it be?
Here's how fast it looks with the first-render unblocked and redundant CSS removed:
Like I said, it isn't an easy fix in this case, but the potential savings are huge.
Unfortunately it's bottom-of-the-table for Ferrari, by some margin, but will they stay there?