September WebPageTest Roundup

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

#anchorOverview

• The custom waterfall page got a significant redesign
• WebPageTest now uses Chrome's Dev Tools priorities
• The Element Timing API is now supported
• The Locations API endpoint can be filtered by a single location
• We now warn you if we think your TTFB might be inaccurate

#anchorCustom waterfall redesign and dynamic adjustments

One of the (many) features that is a little tucked away in WebPageTest is the ability to customize the waterfall by choosing what metrics and information to hide or display, truncating the waterfall to a given duration and even zooming in on individual requests.

It's a handy way to zero in on a subset of the waterfall when you're trying to demonstrate a particular issue or document what needs to happen for a particular optimization.

This month, the page got a significant facelift, making it much easier to quickly update the waterfall and improving the overall accessibility and usability of the page.

#anchorChrome Dev Tools Priorities

Browsers apply different priorities to resources depending on what type they are, when they're requested and how. This helps them to properly prioritize resources to make sure the most important ones are dealt with first.

Chrome has 5 priority levels, but the names of those priorities varies depending on which part of the browser stack is involved. There are priority names in Blink, in the Net Stack, and then the priority names used in Dev Tools.

WebPageTest has historically reported the underlying names exposed via Blink and the Net Stack, but we will now use the Dev Tools priority names.

This doesn't change or mask underlying information in anyway, but with significant work happening in Chrome around priorities in general (with some major preload improvements and their experimentation around priority hints), it makes sense to unify around one set of names to make that experimentation and discussion much more cohesive.

#anchorElement Timing API

One of the more exciting developments in performance metrics in the past few years has been the introduction of API's that allow folks to start tracking very customized metrics, based on what matters most in their sites or applications. One of the latest of these is the Element Timing API, which lets you measure when a particular image or text node is displayed on the screen by adding an elementTiming attribute to the element in your markup.

<img src="image.jpg" elementtiming="big-image">

While the Element Timing API has been supported in Blink-based browsers (Chrome, Opera, Samsung Internet, Edge) for awhile now, there weren't any trace events reported to ensure the most accurate data in a synthetic test. We asked the Chrome team if they could add those, and they quickly jumped on it, enabling us to now expose Element Timing information in your WebPageTest results!

Now, if you use Element Timing on your page, those metrics will be reported in the JSON results for the test, as well as the metric summary for the test runs.

You can also optionally expose them on the waterfall from the Custom Waterfall page.

#anchorFilter locations endpoint by specific location

The locations endpoint for the API lets you check what test locations are available, what browsers are at each location, and what the overall status is for each.

A few folks had let us know they wanted to be able to query for a single location instead, so we added an optional location parameter to the endpoint so that you can grab the status of a single location at a time.

# This will return the status of the ec2-us-east-1 location only
https://webpagetest.org/getLocations.php?k=A&f=json&location=ec2-us-east-1

#anchorFirst-Byte Warning

During one of our WebPageTest Live Twitch streams, we ran into a situation where the Time to First Byte for one of the tests was very high, coming in a whopping 9.237s! Eventually, we discovered that it was due to a bot mitigation tool that was identifying our test agents as a bot, and artificially delaying the Time to First Byte as a result. WebPageTest's Preserve User Original User Agent String feature strips out the WebPageTest specific information in the UA String and avoids the issue, giving you accurate results, but it took us a bit to realize what was going on.

To make that process easier for everyone (including us!), we added a warning to test results with abnormally long Time to First Byte's suggesting to re-run the test with the original User Agent string preserved.

To minimize the risk of over aggressively warning, the warning is only displayed if the Time to First Byte for all runs of the test is over 3 seconds.

Accuracy of your test results is very important to us, and our hope is that this addition helps folks avoid spending time digging into issues that aren't actually there.