September 2022 WebPageTest Roundup

It’s been a while, but we’re bringing back our monthly product round-up to make it easier for folks to stay up to date with all the new features and improvements around WebPageTest.

#anchorOverview

• Free Web Performance Course!
• Remove TTFB variance from experiment comparisons
• More events supported in the Chrome Recorder extension
• Pass through the current test ID in custom script
• Blacklist, custom scripts, custom metrics and more now support file input
• Ability to report the time until the title is displayed for Chrome tests

#anchorFree Web Performance Course!

WebPageTest has benefitted so much from the performance community over the years, and it’s very important to us that we give back to the community by finding ways to support, educate and empower folks in their performance journey.

To that goal, we’ve launched “Lighting Fast Websites”—a perfect course for introducing you to web performance, taught by Scott Jehl. Scott had published the course on his own before joining WebPageTest, but now we’ve updated it and made it available for free to anyone with a WebPageTest account.

If you’ve already got a WebPageTest account, you can access the course right now and get started. If you don’t have an account, you can register today (did we mention it was free?) and get immediate access to the course, as well as all the other benefits of a WebPageTest account.

And stay tuned. Investing in the community by providing educational resources is important to us, and this is just the start.

#anchorRemove TTFB Variance from Experiment Comparisons

As people have been running more and more experiments, one thing we’ve heard from folks is that sometimes server variability (something almost always unrelated to the experiment itself) makes it hard for folks to see the direct impact of an experiment.

To help with that, if you run an experiment and there is more than 100ms of difference between the median control and median experiment runs, WebPageTest now surfaces a note pointing out that the difference in Time to First Byte may be skewing the results of the experiment, with a quick link to view the results with the Time To First Byte removed from any relevant primary metrics.

Variability still matters and often hints at other performance challenges, so we also provide a quick link to the plot full results page so you can dig deeper into the variability between runs.

In the example below, you can see how our original experiment looked like it made things slower, but that’s because there was a 1.14s difference in Time to First Byte.

When you remove TTFB from the equation, you can see the experiment does have a positive impact on rendering metrics.

Accurate, reliable experiment data is very important to us, and this improvement should make it easier to zero in on meaningful changes in performance data.

#anchorMore events supported in the Chrome Recorder extension

Last month’s release of the WebPageTest Chrome Recorder extension instantly made writing custom scripts and testing user journey’s in WebPageTest much easier, and we’ve made it even better. This month we mapped the following Chrome Recorder commands to WebPageTest script commands to make the export even more useful:

• waitForElement
• waitForExpression
• doubleClick
• scroll

In addition, if you use setViewport in the Recorder panel, we’ll now use that to set the viewport of your test in WebPageTest.

We’ve been getting a lot of positive feedback on how useful the extension has been. If you’re using it, we’d love to know what else could make it even better.

#anchorPass the Current Test ID through in Custom Scripts

WebPageTest supports several handy variable substitutions for custom scripts that let you pass through, for example, the current test URL (%URL%) or the host of the current test URL (%HOST%).

Based on user feedback, we also provide variable substitution for the test ID of the currently running test. If you include %TEST_ID% in your custom script, as soon as we create the unique test ID for your test, we’ll replace any %TEST_ID% references with the ID instead.

Let’s say that you wanted to analyze your own internal logs to see what’s happening deep within your stack for a particular WebPageTest run. You could use the %TEST_ID% variable to ensure that the unique ID is present in, say, a query parameter.

navigate %URL%?%TEST_ID%

That test ID then gets passed through to the test.

You can now look through your logs, or any APM setup you have, to find that distinct ID and see what’s happening in your application stack during the test run.

W e're excited about the power this has to unlock even deeper analysis when used in conjunction with a rock-solid APM solution.

You can read about all of the variable substitutions we support in our docs.

#anchorBlacklist, custom scripts, custom metrics and more support file input

Each textarea input in our test form now supports file input, making it easier for folks to save your favorite scripts and more as files and use them directly, rather than having to retype everything.

Where it makes sense, we’ve also started adding some syntax coloring to the fields to make it easier to read through what you’ve input and spot potential issues.

We’ve got more in store for making it easier for folks to reuse favorite scripts and run advanced tests with confidence, so stay tuned!

#anchorAbility to report the time until the title is displayed for Chrome tests

For Chromium-based tests, we will now parse out the titleTime from the traces: the time it takes for the page title to be displayed during the page load process.

The titleTime is currently available in the JSON data for each test run, so it’s best consumed using the WebPageTest API today.