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.

If you want to generate page load waterfalls for iOS Safari the current options are Mobitest / WebPageTest or Safari on OSX.

Mobitest and WebPageTest are great tools (essentially the same tool underneath) that I often use but they have a few limitations:
- there's a limited number of test locations so latency can complicate testing
- uses a UIWebView so any javascript in the pages doesn't have access to the JIT

Safari on OSX is OK but there seems to be no way of generating a HAR file from the waterfall view in developer tools.

These limitations sometimes frustrate me so I decided to write a generator that creates HAR files from Safari running on the iOS Simulator (actual physical iPhones and iPad support will hopefully come too).

A few days ago, Mark Boulton bounced around the idea of Sparkicons, small inline icons at the end of links, that indicate what's on the end of a hyperlink.

Based on meta-data attached to a link, the Sparkicon could indicate the link is to a PDF, or a video, or a discussion thead. It could also include addition information such as how long a video is or how many comments there are in a discussion thread.

This is one way they could be implemented...