Why

The performance of a website has never been more important. Times are tough, competition never rests, and so forth.

If your website doesn’t load fast, or doesn’t feel “stable” to your users, or your users can’t interact with your website fast, you are in trouble.

But finding out whether your site has these problems is not always easy. Your site might load just fine on your device using your Internet connection, but all of your users do not have your device and Internet connection.

So you need to test your site using varying connection speeds, from varying locations (perhaps from varying locations around the world).

And once you’ve done our testing, you need to be able to investigate the findings, determine if you have problems, what might be causing those problems, and then test again after you think you might have fixed the problem.

This is where WebPageTest comes in.

What

WebPageTest (WPT) is an online tool for measuring the performance of a webpage.

The site lets you submit a URL, pick from numerous configuration options, and test the site’s performance “in real browsers, devices, and locations around the world”.
The WebPageTest blog contains numerous posts to guide users through the site, but it can also be a bit overwhelming…

To help you more easily conduct tests related to your website(s), I have created a series of walk-through articles.

So, let’s get to know WebPageTest!

Getting Started

The WebPageTest blog contains numerous posts to guide users through the site, but it can also be a bit overwhelming…

To help you conduct a basic performance test, we have created the walk-through below:

• Create a test
• Read a test
• Share a test
• Find previous tests
• Re-Run a Test

Create a test

Even a basic test for any ELC site requires some configuration.

Below we describe the configuration options available and the process for setting those configuration options for a basic ELC site test.

1. Go to: https://www.webpagetest.org/
2. If you have an account, make sure you are logged in; if not, create one.
3. Choose Test Type and enter URL:
   
   1. WPT offers multiple types of tests, but we want the Site Performance option, so choose that from the dropdown
   2. Then paste the URL of the page you wish to test.
4. Choose Test Location and Browser:
   While WPT does offer a Simple Configuration, we actually need the Advanced Configuration, so click that option.
   Once the Advanced Configuration panel opens, complete the options as follows:
   
   1. Choose a location that is appropriate for the site you are testing. In this example, the site is NA, so I am choosing a location in the US. If I were testing a site in Japan, I might choose Tokyo.
   2. Choose a browser. If the site is a mobile site, our standard is to choose iPhone X. If the site is a desktop site, our standard is to choose Chrome.
   3. Note that in some cases your test might end up in a queue. If you need that specific location, you can go ahead and start your test, but it will have to wait for the other tests to finish before it can start. If you have other location options available (such as NA, which also has Salt Lake City, California, Toronto), you could try picking another location to see if one is less busy.
5. There are multiple tabs below the above section, so let’s walk through each…
6. Test Settings tab:
   
   1. Connection: For mobile, choose LTE (12 Mbps, 70ms RTT); for desktop, choose Cable (5/1 Mbps, 28ms RTT).
   2. Desktop Browser Dimensions: Leave as-is.
   3. Number of Tests to Run: Typically 1 is fine; if you are testing caching or similar, you might choose something higher.
   4. Repeat View: Typically First View Only is fine; if you are testing caching or similar, you might choose First View and Repeat View.
   5. Capture Video: Always check this option.
   6. Label: Labels help you recognize historical tests. We recommend something that represents Brand Location Page Device, like EL NA Home Mobile. Your situation may vary, so do what makes sense to you, but having a consistent pattern will make historical searches easier.
7. Advanced tab:
   This tab has a lot to offer, but I will highlight just a few:
   
   1. Should a site have an invalid SSL, this checkbox allows you to ignore that issue.
   2. Saving the response body not only captures the exact HTML delivered to the browser, but is also key to an incredible Opportunity, to be discussed later.
   3. The description for this option explains itself nicely. :-)
8. Chromium tab:
   This tab has a lot to offer, but these are the only options that are critical for a basic test:
   
   1. Capture Lighthouse Report: Always check this option.
   2. Emulate Mobile Browser: If you are testing a mobile page, check this option; if desktop, uncheck it. (Note that you cannot remove the device from the dropdown, but unchecking this option will ignore it.)
   3. Capture Dev Tools Filmstrip: You may or may not find this useful in your testing, but it could be useful if you find a problem that requires an engineer’s eyes, so we recommend leaving it checked.
9. Script tab:
   This tab is not used often, but it allows you to perform tasks before or after a page loads, such as adding cookies. The page offers a link to their documentation at the bottom of the page if you need to do anything here.
10. Block tab:
    This tab is not used often, but it allows you to block asset requests based on URL substrings or domain names.
11. SPOF tab:
    This tab is not used often, but it allows you to simulate a Single Point of Failure, based on domain names.
12. Custom tab:
    This tab is not used often, but it allows you to add custom performance metrics. The page offers a link to their documentation at the bottom of the page if you need to do anything here.
13. Start the test:
    
    1. Once you have the test configured, scroll toward the top and click the big yellow Start Test button.
14. Once a test has started, the page will refresh and show a message similar to this:
    
15. This page will update silently, telling you when the test has started…
    
16. And eventually your test results will appear. See the next section for interpreting the test results.

Read a test

Once your test results are ready, the same page will silently refresh to show your results.

The results of the test above can be seen here, in case you want to “play along at home”:
https://www.webpagetest.org/result/220804_BiDcTG_B78/

Now, let’s walk through those results!
(There are a lot of options in these results, so we will only cover some of the basics.)

1. The top of the page displays the top-level test details:
   
   All of this information should seem familiar, based on the section above, but note the More dropdown, which lists even more of the test details, such as the Script tab, etc.
2. Right below the above section is the following:
   
   The View dropdown allows you to jump to various sections of the test results; the Export and Re-Run Test options can be extremely helpful!
3. The first major set of stats that you will see is below (note that both the Metrics and the Filmstrip scroll to the right).
   
   1. Most of these KPIs should be familiar to you, but note that several are clickable, providing deeper details and explanations.
   2. The Filmstrip provides visual steps through the page load experience.
   3. Scroll to the right to see more of both.
4. Below the Observed Metrics section are several graphics demonstrating where this page lands within each of these KPIs:
   
5. Below the Real User Measurements section are several very useful links:
   
   The most useful bits are probably:
   1. Waterfall: Click the waterfall graphic to see a larger, interactive version. This demonstrates how assets arrived in the browser and loaded, visually demonstrating how one file can affect others and the overall page load experience.
   2. Filmstrip View: Provides a larger Filmstrip that interacts with the Waterfall; as you scroll one, both move to show how assets in the Waterfall affect what is happening on the page; or conversely, when something happens in the Filmstrip, what in the Waterfall might have caused that to happen:
      
   3. Watch Video: Provides a downloadable video showing the above-the-fold page load experience.
6. Below these sections is the Content Breakdown, showing the percentage of assets and bytes grouped by asset type:
   
   Note that you can hover over each section of the pie charts to get the actual percentage/bytes, and that you can click the link to the left for more detailed information about this section.
7. As mentioned earlier, you can click most of the KPIs in the Observed Metrics section to get more detail about each KPI. The top of the resulting page lists the three Core Web Vitals (CWVs):
   
   Note that each of these is also clickable, taking you directly to that section, providing even deeper details.
8. For example, clicking the Cumulative Layout Shift (CLS) section, jumps down to that section:
   
   1. Note this section first reminds you of the KPI score (in this case, 0.14), then offers links to additional views of this KPI, and “snapshots” of each layout shift that contributed to this test’s CLS.
   2. The snapshots are grouped into numbered “Windows”, each noting how much that Window contributed to the total CLS score (in this case, “Window 1” contributed nearly all of the 0.14 score, and the first snapshot contributed 0.11431 to the total CLS score).
   3. Hovering over each snapshot will reveal what the screen looked like before the CLS; both snapshots try to highlight the element(s) responsible for the related CLS.
   4. In this case, initially there was a large white section above the “LIMITED TIME OFFER” content section. Then the hero image loaded and shifted the highlighted content down:
      
   5. Note that the Windows may not always be in order, each Window may contain multiple snapshots, and the snapshots within each Window may not be in order. But each snapshot does have a timestamp below it (in this case, this snapshot was taken 5.368 seconds into the page load), so you can “piece together” the proper sequence, if necessary.

Share a test

Once a test has completed, you might want to share these results with someone else.

You can always just grab the URL and paste it somewhere, but WPT also offers, at the top of every results page, several convenient Share options:

Find previous tests

Once a test has completed, you might want to revisit that test at some point in the future.

Perhaps you simply want to verify what you remember, or you wish to run the exact same test again (exact same URL, exact same test configuration).

This is a very likely scenario, where a problem was observed earlier, and that problem has now been marked as resolved. You would want to run the exact same test to prove that the solution had the intended impact. And having the exact same test configuration is vital to having confidence in the test comparisons.

To view previous tests:

1. Go to: https://www.webpagetest.org/
2. Make sure you are logged into the same account used for running the previous test.
3. In the main menu, click the Test History link:
   
   Note, on mobile, this menu is rolled up under a burger icon in the top-right of the screen.
4. Once the page loads, you will see all of the tests that you ran with the last 7 days:
   
   1. The default view is the last 7 days, but you can easily change that via the dropdown at the top of the page. You can also use this search box to find specific tests that you previously ran (which is why we recommended having a specific naming convention for your test Labels).
   2. Your Labels appear in the far-right column. Consistent labeling helps you easily recognize tests of the same page.
   3. Run From tells the Location the test ran from.
   4. Run Date is the UTC date/time that the test ran.
   5. URL is the page URL that was tested.
   6. Select to compare is quite useful in the scenario described above, where a change was made and want to see how it affected the page, compared to a previous test. Simply check the tests you wish to compare, then click the Compare Selected Tests button above the table of historical tests.

Re-Run a Test

Once you have run any test, you can always re-run exactly the same test.

To re-run a previous test:

1. First, login, find the test you want to re-run, and click to view it.
2. Once your test results have opened, you can click the Re-Run Test button:
   
3. This will re-run the exact same test. At the time of this writing, there was no way to edit the test before re-running, nor to use a previous test as a “template” for another test, but both of these options have been suggested.

This completes our intro to WPT! There is much more to this incredible tool, but hopefully this helped give you a taste of what it can do.

If you are looking to do more (like maybe start using their API! :-), there are tons of useful posts & videos online, including the WebPageTest blog, and I would be happy to help with any questions you might have!

Thanks a lot for following along, and please, let me know if you think I missed anything or if you differ with my interpretation or understanding on something. My goal here is for everyone to read this and get to know this topic better! And you can help with that!

Happy testing,
Atg

Top⇪