The pre-loader (also known as the speculative or look-ahead pre-parser) may be the single biggest improvement ever made to browser performance.

During their implementation Mozilla reported a 19% improvement in load times, and in a test against the Alexa top 2,000 sites Google found around a 20% improvement.

ItÁ€™s not a new browser feature but some seem to believe itÁ€™s Chrome only and yet others suggest itÁ€™s Á€œthe most destructive Á€˜performance enhancementÁ€™ thereÁ€™s ever beenÁ€«!

So what is the pre-loader and how does it improve performance?

With our current tools itÁ€™s relatively easy to examine the performance of a single page, or the performance of a journey a visitor takes through a series of pages but when I examine a clientÁ€™s site for the first time I often want to get a broad view of performance across the whole site.

There are a few tools that can crawl a site and produce performance reports, SiteSpeed.io from Peter Hedenskog and NCC GroupÁ€™s (was Site Confidence) Performance Analyser are two I use regularly.

Sometimes I want more than these tools offer - I might want to test from the USA or Japan, or want some measurements they donÁ€™t provide - thatÁ€™s when I use my own instance of the HTTP Archive.

Like most people involved in web performance I spend hours looking at page load waterfalls, each one tells it’s own story and the patterns hint at where the issues are.

With tools like Mobitest, WebPageTest, remote debugging in Chrome and Safari I can get a good level of detail for modern mobile browsers but I often want to test on older devices where the dev tools support isn’t as good or more commonly non-existent.

A proxy like Charles is one way of generating HARs from old devices but using a proxy can alter the waterfall so I prefer to generate waterwalls from a TCP packet capture.

I’ve been helping a client identify some performance issues with a new hosting platform they’re in the process of commissioning.

The new platform has New Relic running but unfortunately it only provides an average for response times. Averages can hide all manner of sins so I prefer to look at the distribution of response times, I also wanted a way to compare against the existing platform which has no monitoring on it.

The method I chose was to add time taken to the IIS logfiles and plot histograms using R.

Back in September I explained how to create a private instance of Web Page Test running IE, Firefox and Chrome on Windows 7.

Recently I needed to add some iOS agents, after a bit of trial and error this is the approach I used.