Getting started with WebPagetest
Posted in: Getting Started   -   August 1, 2012

Optimization (performance or otherwise) is usually a cycle of measure -> analyze -> adjust, repeated over and over until you reach your goal.  There are a ton of great tools and services for measuring the performance of a website but the basics are all generally the same.  As an introduction into the world of web performance, here are the basics that you would want to look at, using WebPagetest as the measurement tool for demonstrating.

Step 1 – Understand your user base

Before even going into the optimization cycle you’ll want to make sure you understand YOUR specific user base.  This typically means looking at your analytics to see: – What are the most used browsers by your users? – Where in the world do your users visit from? – What pages do your users visit most? This is critical because you want your measurements to be as close as possible to what your users are actually doing.

Step 2 – Measure

Go to WebPagetest and use the information you gathered in step 1 to select a good test location (close to your user base), browser and URL for testing and submit the test.  Don’t worry about the advanced settings yet, you’ll want to take a look at the basics first.

WebPagetest Main Screen

Step 3 – Analyze

When the test has completed running you will be presented with an intimidating screen of information about the page tested.  Don’t get scared off, there is a lot of useful information in there:

The first thing you will want to look at is the summary information in the data table at the top of the page.  Specifically you want to look at the Load time, First Byte time and Start Render times.  These give you measurements for how long it took to load the page (Load time), how long it took your web server to respond with the base HTML for the page (First Byte time) and how long it took before something was displayed to the user (Start Render time).

Next you will want to look at the grades at the top of the results.  I generally frown on automated recommendations but the checks done for the grades are universally applicable and if you are not getting an A or a B for all of them you should fix that before doing anything else.  They are largely system configuration items and can have enormous impacts on site performance (fixing any one of them can usually cut load times in half) and are prioritized from left to right (left being the most important).  Clicking on the letter grade will take you to a list of resources that caused the check to fail.  The one exception to “universally applicable” is the Content Delivery Network (CDN) check.  If your users are all visiting your site from a small geographic area (say, all from within Europe) and your site is hosted near the users then a CDN is not necessary but otherwise it is usually a big win.

After you have covered the basics you will spend most of your time working with the waterfall view.  The waterfall is a time-series plot of every resource (image, JavaScript, CSS, etc) that the browser loaded from the network in order to display the page.  Click on the thumbnail of the waterfall to open a larger view.

Each row in the waterfall is a resource loaded and time is plotted horizontally.  Each of the rows in the waterfall has multiple components.  At a minimum, each row will include a request time (green) and download time (blue).  The request time measures the time from when the browser sends a request to the server until it starts to receive the response (for an image for example).  The download time is the time it took to download the response provided by the server.  Additionally, each row may have a socket connect time (orange) if the browser had to open a new connection to the server and a DNS lookup time (grey) if the browser needed to look up the server name to figure out where to connect to (it will generally do this once each for every domain it needs to request content from).  The colors will be different depending on the tool you are using but the order and components will always be the same.

When you are looking at the waterfall you will generally be looking for any opportunities to move everything to the left.  This can be a combination of looking for expensive/slow requests, reducing the number of requests, moving things around or identifying choke points.  If you see a break in the waterfall flow that is usually a good place to look for something in the code or layout that is causing the browser to pause and eliminating those can be a big win.  The forums on WebPagetest are a great place to ask questions and get feedback on understanding your specific test results and places to look for performance improvements.

Once you have identified the areas you want to focus on, you’ll want to iterate on implementing fixes and running more tests to measure your progress.  Sometimes things move around and hotspots change when you change the site so you’ll want to re-evaluate the analysis frequently.


One of the most powerful features of WebPagetest is the ability to record video of the page loading.  It’s important to understand the actual user experience because the technical measurements may be misleading.  You can enable video capture in the advanced settings:

Then on the results screen you will get an option to view the filmstrip view of the test result:

In the filmstrip view you will have a scrollable view of the page load with screen shots every 0.1 second and a corresponding waterfall.  This is a great way to find bottlenecks that delay visual elements from displaying.

Just the Tip of the Iceberg

There are a lot of other capabilities offered with WebPagetest, mostly through the advanced settings.  Fell free to explore around (you won’t break it) and ask questions if there is something you are curious about.

Patrick Meenan (@patmeenan) created WebPagetest while working at AOL and now works at Google with the team that is working to make the web faster.

Tags: , , , ,

  • Mike Keller

    Nice post Patrick!

  • eks

    Thank you!! I got all I need to understand =) powerful tool!