Andy Davies

Independent Web Performance Consultant

Improving Perceived Performance With the Link Rel=preconnect HTTP Header

Sometimes a small change can have a huge effect…

Recently, a client switched from serving their product images through AWS S3 and Cloudfront to Cloudinary.

Although Cloudinary was delivering optimally sized and better compressed images, there was a noticeable delay before the images arrived, and some of this delay was due to the overhead of creating a connection to another origin (the delay existed with the S3 / Cloudfront combination too).

Preloading Fonts and the Puzzle of Priorities

“Consider using <link rel=preload> to prioritize fetching resources that are currently requested later in page load” is the seemingly simple advice Lighthouse gives.

Preload is a trade-off – when we explicitly increase the priority of one resource we implicitly decrease the priority of others – and so to work effectively preload requires authors to identify the optimal resources to preload, browsers to request them with optimal priorities and servers to deliver them in optimal order.

Some resources are discovered later than others, for example resources injected by a script, or background images and fonts that are only discovered when the render tree is built.

Preload instructs the browser to download a resource even before it discovers it but so there may be performance gains by using <link rel=preload to download resources earlier than normal.

Preload also allows us to decouple download and execution, for example the Filament Group suggest using it to load CSS asynchronously

I’ve being using preload with clients over the last few years but I have never been completely satisfied with the results. I’ve also seen some things I hadn’t quite expected in page load waterfalls so decided to dig deeper.

Safari, Caching and Third-Party Resources

“Note that WebKit already partitions caches and HTML5 storage for all third-party domains.” - Intelligent Tracking Prevention

Seems a pretty innocuous note but…

What this means is Safari caches content from third-party origins separately for each document origin, so for example if two sites, say a.com and b.com both use a common library, third-party.com/script.js, then script.js will be cached separately for both sites.

And if someone has an ‘empty’ cache and visits the first site and then the other, script.js will be downloaded twice.

Malte Ubl was the first person I saw mention this back in April 2017 but it appears this has been Safari’s behaviour since 2013

So how much should we worry about Safari’s behaviour from a performance perspective?