#ASKTHEINDUSTRY 35: What is WebPagetest.org?

Alessandro Menduni
West Wing Solutions
3 min readMar 21, 2017

Testing a web page is a hell of a journey. One cannot simply hit refresh in the browser locally to see whether things work as expected. Why? Because, when we do so, two aspects tend to be dramatically different:

  1. The machine we are running our tests on is way more powerful than the actual device the site gets run on (typically a medium-to-low-end phone)
  2. The network conditions are incomparably better than the ones our users will be in at the time of browsing our site. This is also true even if we enable some kind of network throttling in the Dev Tools

For this reasons, many developers in the industry need other go-to tools when testing for performance. We are all left with the only solution of going around with different mobile phones and execute our tests on those.

Alex Russell showing its testing kit at the Chrome Dev Summit 2016

Luckily, the community can count on a great tool called WebPagetest, which is an open source project that offers the possibility to run tests on a different range of devices and network conditions.

Best of all, it is completely free. Yep, you read that right.

What can WebPagetest do for me?

It can run speed test from multiple locations around the globe, using real browsers and at real consumer connection speeds (quoting the homepage here). Not only you can choose device, browser and connectivity conditions. You also get awesome performance reporting as a result: a film view of what got painted and what point in time, a breakdown of the network requests, a JavaScript timeline, plus a ton more of information.

On a typical day, I use it as follows:

  • Pick Moto G (gen 1) as test locations
  • Set Mobile 3G — Slow as connection
  • Select First View and Repeat View
  • Select Capture Video
  • Hit the Start Test button

As you can easily imagine, WebPagetest gives you the possibility to test webpages on a low end device such as the Moto G, on a slow connection, and to record (and possibly compare) both the first view and repeated views. This may be especially useful to see what’s the impact of the browser cache, or of the Service Worker, on your project.

Measuring is just half of the trip though. You should probably know your metrics, and have an auditing process. Feel free to steal mine:

If you’ve found this post useful at all, press the ❤ button! I read each and every comment, so be sure to contribute to the conversation with your thoughts!

--

--

Alessandro Menduni
West Wing Solutions

JavaScript Engineer, passionate about testing JavaScript and software architecture