Many performance techniques focus on improving the performance of the current page, but there are some that help with the performance of the next page – caching, prefetching, and prerendering for example.

The Prefetch Resource Hint allows us to tell the browser about resources we expect to be used in the near future, so they can be fetched ready for the next navigation.

Several of my clients have implemented Prefetch – some are inserting the markup server-side when the page is generated, and others injecting it dynamically in the browser using Instant Page or similar.

A while back I noticed Chrome was making requests for prefetched resources much earlier than I expected and in some cases the prefetched resources were competing with other more important resources for the network.

As the specification makes clear this is something we want to avoid:

Resource fetches required for the next navigation SHOULD have lower relative priority and SHOULD NOT block or interfere with resource fetches required by the current navigation context.

So how do browsers behave and what are the implications of which server is in use?

I often want to examine the web traffic generated by browsers, and other apps.

Sometimes I can use the tools built into browsers, other times proxies, but when I want to take a deeper look and particularly if I’m looking at how a browser is using HTTP/2, I rely on packet captures.

One challenge with analysing HTTP/2 traffic is that it’s encrypted and while Chrome and Firefox support logging TLS keys and tools like Wireshark can then decrypt the traffic.

Safari and iOS doesn’t have this feature natively, and proxies like Charles only communicate to the browser via HTTP/1.x so I needed to find another solution.

In this post I walk through how I capture iOS apptraffic using tcpdump, and how I use a Frida script to extract the TLS keys during the capture so that I can decrypt the traffic too.

The preconnect Resource Hint is a great way to speed up content that comes from third-party origins – it’s got relatively low overhead (though it’s not completely free) and is generally easy to implement.

Sometimes it produces small improvements, and sometimes more dramatic ones!

Browsers typically only make a connection to an origin just before they request a resource from it, so when resources are discovered late such as CSS background images, fonts, or script injected resources, or resources are considered a low priority, as Chrome does with images, the delay in making the connection becomes part of the critical path for that resource.

After explaining the preconnect Resource Hint to clients or workshop attendees, I often get asked “How can I check it’s working?”

Here's a few ways of checking:

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