May WebPageTest Roundup

Things can move pretty quickly around here, so in addition to the new change log, we're going to start publishing monthly summaries of some of the highlights of features and changes made to WebPageTest in the last month.

#anchorImprovements to the Plot Full Results Page

The Plot Full Results page (one of Matt Hobb's personal favorites) got a few helpful improvements.

The Plot Full Results page is used to let you see the results of each individual run of a test (or several tests) so that you can more easily spot outliers and see the variability in your results.

To help make sharing and comparing easier, you can now force each chart to start at zero for the y-axis to make it easier to share and compare results. Before, the charts would auto-scale the y-axis, which worked well if you were viewing one chart in isolation, but not if you wanted to compare and contrast charts from different tests.

If you're graphing the results of multiple tests, we also now provide a summary table of the results for each of the tests you're plotting.

#anchorA New Way to Diagnose Core Web Vitals Issues

As companies ramp up their efforts around Core Web Vitals, we wanted to arm folks with the tools and information they need to more easily identify why a particular vital metric may be slow and how to fix it. Frankly, Pat and I got tired of digging through the raw JSON of each test result so we made a page to start surfacing helpful diagnostic information.

The page is actively being worked on, but already this month we've added a bunch of information and visuals to help.

Largest Contentful Paint

For Largest Contentful Paint, we provide the screenshots from the filmstrip of when the LCP event fired, as well as a before and after screenshot to help visualize what is triggering LCP.

We also provide a summary of the LCP event itself, including the outer HTML and, if it's an image, the image src.

Finally, we also provide a truncated version of the waterfall, cut off at the moment LCP occurs so you can focus just on the resources that may be delaying it. If an image is what triggers LCP, we automatically highlight the request in the waterfall so that you can very quickly zero in on when it's being loaded. We also display the image itself at full size, below the waterfall.

Cumulative Layout Shift

For any layout shifts, you're able to hover over a screenshot to see an animation of what shifted on the page.

Total Blocking Time

Under Total Blocking Time, we provide a version of the waterfall that focuses specifically on requests that trigger JavaScript execution.

Below that, we also provide a quick link to the Chrome Developer Tools Performance Panel from the test, as well as a breakdown of the main thread blocking time by script origin.

Watch for more information about this page, as well as further improvements. We've got a few nifty (yeah, I said nifty) ideas for what we want to do here to make it even easier to troubleshoot vitals issues in the future.

#anchorExposing the Accessibility Tree With Custom Metrics

We can now capture the Chromium Accessibility Tree with a custom metric ($WPT_ACCESSIBILITY_TREE), making it possible to analyze and opening the door for us to provide some interesting accessibility checks in the future. Learn more in the documentation about how to collect the tree and definitely let us know if you've got anything you're excited to do with it.

#anchorWebPageTest for Slack

Thanks to the work of Abdul Suhail, we now have a Slack bot for WebPageTest!

The bot uses the WebPageTest API to enable you to trigger WebPageTest tests from within Slack, and get the results automatically posted back to the appropriate Slack channel. As more companies use Slack as a hub for alerting and debugging, bringing WebPageTest results into that process makes it easier for teams to diagnose problems quickly.

You can learn more about the Slack bot in the detailed documentation found in GitHub.

#anchorNew Origin Variable Substitution and Documentation

WebPageTest supports a few variable substitutions in our custom scripting, but they were undocumented. Thanks to the work of Anthony Ricaud, there's now documentation for each variable supported.

Anthony also added a brand new variable (%ORIGIN%) which can be used to substitute the origin of the URL being tested.

URL: https://wpt.example/hello
input: setCookie  %ORIGIN% foo=bar
output: setCookie https://wpt.example foo=bar

#anchorMore Accurate CPU Emulation

Pat recalibrated the CPU throttling for mobile emulation to make the results more accurate and in line with how the actual mobile devices perform. For most devices, this required about twice as much throttling. Any mobile emulated tests should now be much more accurate.

#anchorUpdated Wappalyzer Engine

WebPageTest runs Wappalyzer on each test run to help identify what technologies are used on a given page. We updated to the latest version of the engine, which provides support for a bunch of new technologies, as well as improved detection for others.