"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.

"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?

There's been an explosion in 3rd-Party Tags…

And as Tim Kadlec once said "Everything should have a value, because everything has a cost".

So how do we measure the performance cost of all the 3rd-party tags we keep adding to our sites?

If you’ve got your own Private WebPageTest instance, and you want to add extra locations without setting up the test agents yourself then you can add agents from another instance.

Once configured your local WebPageTest instance submits tests and retrieves results via the API of the remote WebPageTest instance (aka Relay Server), and the pages are tested on the remote instance’s agents.

Using a Relay Server is also handy if you want to do local development on the server code without needing to setup Windows (or mobile) test agents.

So Google, a group of publishers and others have launched Accelerated Mobile Pages (AMP)

AMP promotes the goal of a faster mobile web which is something I think we’d all like to see.

If you visit g.co/ampdemo on a mobile, and search for ‘Obama’ there’s no doubt the stories in the carousel come up fast, and moving between them is slick too. The demo isn’t available in all regions yet so Addy Osmani posted a demo to YouTube.

Similar to Google’s Instant Pages, AMP relies on pre-rendering and caching to make the pages load instantly.