If you are on an Enterprise plan you can add WebPagetest scripts to the URLs you test. When you edit a Site in your Settings there's a script icon next to each URL that allows you to add scripts.

Not on an Enterprise plan? No problem! Get in touch with support@speedcurve.com to see if you can trial WebPagetest scripts on your current plan.

With WebPagetest scripts you're able to do all sorts of things like add headers, set cookies, step through a number of pages or perform actions on a page like logging in or adding an item to a shopping cart.

We recommend working up a script using WebPagetest.org and then once you've confirmed it's working adding it to your SpeedCurve account. The WebPagetest scripting documentation has all the options available and includes example scripts at the bottom of the page.

SpeedCurve scripting caveatsĀ 

There are a few things to be aware of when writing WebPageTest scripts for SpeedCurve.

Results must contain a single step

More complex scripts will sometimes end up generating results with multiple steps, like this:

SpeedCurve will not be able to parse these results, because it does not know which step to use as the final result. You can avoid generating multiple steps by putting combineSteps at the top of your script.

The setEventName command is not supported

The setEventName command creates an extra step in the test results, which SpeedCurve cannot parse (see above). You should avoid using this command in your scripts.

WebPageTest scripts don't work in Lighthouse

Lighthouse doesn't support WPT scripting.

Extra SpeedCurve Script options

speedcurve_removePTST 1

We've added support for preserving the user agent string and not adding "PTST". Some ad providers block all requests which include "PTST" in the user agent and this can skew your metrics if you're wanting to test the full page load with ads. To remove "PTST" from the user agent string you can add "speedcurve_removePTST", a tab, and then "1" to your script to remove it.

speedcurve_clearcerts 1

Clears the OS certificate caches which causes IE to do OCSP/CRL checks during SSL negotiation if the certificates are not already cached.

Script Templates

There are a number script templates available that will generate a script for you using the URL field.

Repeat View
Loads the page a second time allowing you to measure the cached performance of the page.

Block Third Party
Only allows requests for the first party domains listed. Great for blocking all third party requests to ad providers, analytics tags etc. so you can measure the performance of the assets you control. Once you add the script you can manually edit it to add more space delimited first party domains if needed.

PWA: Repeat View While Offline
Progressive Web Apps are great for delivering content while offline. This script loads your PWA, then blocks all network requests and reloads the page again allowing you to check what the offline performance is like and ensure that the user experience is still rendering via the filmstrips.

Don't add 'PTST' to user agent
Some ad providers block all requests which include "PTST" in the user agent and this can skew your metrics if you're wanting test the full page load including ads. This script adds "speedcurve_removePTST" which does what it says on the tin.

Debugging Scripts

Webpagetest scripts can be quite brittle and it's important to get the formatting correct. Please try these steps:

  1. Tabs - Scripts should be tab delimited with only some options accepting spaces between values. This is often the main cause of issues, so check your script in an IDE with invisible characters shown to ensure the formatting is correct.
  2. Hidden errors - Many scripts use "logData 0" to hide steps. If you're having issues try removing the "logData 0" command so that you can identify where in the script the test is failing.
  3. Use webpagetest.org - For quickly iterating over script variations use public WebPageTest to run one off tests. This also helps debug if the issue is SpeedCurve related or not. Watch out for tip #1 when copying and pasting scripts back to SpeedCurve though as they must used tabs.
  4. Use the "exec" command for manipulating the page rather than the built-in commands like "setValue". The "exec" command runs arbitrary JavaScript, which means you can test and debug the JS in your browser console before using it in a test script.
  5. Only use the "andWait" version of commands like "execAndWait" when the command will cause a page transition.
  6. Multi-step scripts - SpeedCurve does not yet support extracting waterfall charts from multi-step scripts. Instead use "logData 0" at the beginning of the script and then "logData 1" just before your final step to record just a single step or navigate command.

Read more:

Did this answer your question?