August 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.

#anchorMaking it easier to Experiment

Third-party performance problems are incredibly common, and one of those issues that folks frequently find themselves wanting to better understand. WebPageTest provides a few helpful options for gauging their impact and this month we made it easier to use them with the new "Experiments" feature.

The SPOF test lets folks see how a site performs when a third-party resource that blocks the initial rendering of the page suddenly hangs (the provider has issues, etc). And WebPageTest also makes it possible to block individual resources from loading, or to block all resources from a given domain, using either the Advanced Settings > Block tab on the test home page, or the block and blockDomains scripting commands.

In the past, running either test required you to go back to the test form and manually enter the URLs and domains you wanted to test.

The new Experiments feature lets you run those tests directly from the waterfall instead, making it much easier to quickly run experiments and test your hypothesis.

If you click on a request on the waterfall, you'll find a new "Experiments" tab in the dialog box that appears.

The tab will provide three possible experiments right now:

• Run a SPOF test (only shown if the resource is render blocking)
• Block Request URL
• Block Request Domain

You can add any number of URLs and domains to block, enter a label to make it easier to find your results later on in your test history, and then run the test all without ever leaving the waterfall.

The ability to run your URL through different scenarios to see how performance is impacted is one of the more powerful and important WebPageTest features. Expect more experiments to be added in the future to make this even easier.

#anchorCleaning up the command bar

There are a number of different artifacts produced for each test you run on WebPageTest:

• A JSON file containing all the metrics and test data (this is identical to what you can get from the API)
• A test log that shows you information about how long it took WebPageTest to run the test and, if there's a failure, where in the testing process it cut out
• A HAR file for additional analysis.
• A Lighthouse test log (if a Lighthouse test was run) detailing how long it took Lighthouse to run and, if there's a failure, where it cut out.
• A zip file containing all the response bodies for any text based responses (CSS, JS, HTML, etc) if "Save Response Bodies" was selected.

Some of these artifacts were spread out, and it wasn't always clear what you could download or access directly, so we cleaned things up a bit to make it easier to get at the information you want.

#anchorAPI endpoint for checking available test runs

Checking your remaining API run balance was only possible in the past by logging into your account and looking at the details of your Subscription Plan (yeah...we know...we're sorry).

In August, we added a new endpoint to the API so that you can programmatically check your remaining balance for the current billing period by passing along your API key.

https://webpagetest.org/testBalance.php?{your_api_key}

If the API key is valid, you will get a small JSON object indicating how many runs you have left:

{
    "data": {
        "remaining": 1175
    }
}

You can find more information in the documentation.

#anchorA new NodeJS wrapper version

We were super excited to work with Marcel Duran to bring his popular API wrapper for NodeJS officially in-house. The wrapper he's built has become the most popular way for folks to use the WebPageTest API, and this makes it much easier for the entire WebPageTest team to keep on top of bugs, feature requests and more.

We put out a new version of the wrapper this month that included some bug fixes and added support for a bunch of missing API parameters as well.

#anchorAdding search to the docs

Thanks to Algolia's build plugin for Netlify, we added search to our documentation site to make it easier to find what you're after.

Selfishly, this is also super helpful for us, as it helps us to see what folks are searching for to help us prioritize which documentation gaps to fill first. For example, we saw that "Lighthouse" was being searched pretty often, so we bumped that to the top of our list and published some information about how WebPageTest runs Lighthouse.

#anchorStatic IP's are here

A lot of folks want to be able to run tests on internal sites (for example, pre-production environments) that are tucked away behind a firewall. We also see a lot of folks trying to work around overly aggressive bot protection services that may block the WebPageTest agents.

To make it a little easier to get around these issues, we've moved all of our EC2 instances to use static IP addresses, making it possible for folks to enable traffic from those specific IP's only so that they can more easily test with WebPageTest.

You can find a full list of test locations and their IP's on the site.