Andy Davies

Independent Web Performance Consultant

Exploring Site Speed Optimisations With WebPageTest and Cloudflare Workers

One of the common questions I'm often asked by clients is "What difference will the changes you're recommending make to our site's speed"?

And too often that can be a hard question to answer…

I can be pretty sure of the 'direction of travel' – shrinking resources should make them download faster, delaying 3rd-parties should make content appear sooner – but page load can be non-deterministic and un-sharding domains, re-ordering resources or other changes sometimes leads to unexpected results.

Knowledge, experience and lots of testing can help us to prioritise what we think are the appropriate optimisations but often we have to wait until those changes make it to staging (or even live) before we can check the results.

Rel=prefetch and the Importance of Effective HTTP/2 Prioritisation

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?

Capturing and Decrypting HTTPS Traffic From iOS Apps Using Frida

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.

Experimenting With Link Rel=preconnect Using Custom Script Injection in WebPageTest

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.