When most people test their site speed, they test a single, static page. That works well for testing home pages, or product pages – but what about a checkout process? Or a page that’s protected behind a login? How do you test more complex, multi-step processes? Luckily WebPageTest (and thus MachMetrics) offers scripting functionality that allows you to create these specific, multi-step tests that can be useful in certain situations such as:
- Testing a page that is only accessible after logging in
- Checking the speed of a checkout process
- Testing with ads disabled
Now for the bad news. The documentation for WPT’s scripting functionality is far from user friendly, and only gives a couple of examples. It lists a lot of the functions that you’re able to use, but it takes some trial and error to bring it all together into a useful script. For this reason, we’re going to go through the above scenarios, and script out a test for each one.
Testing a page behind a log in
This situation is a fairly common requirement for a test, so you’ll likely be able to put this to good use. If your site utilizes a log in, a simple test may only give you a speed audit on how fast your site loads it’s log in form. The more useful information is how fast the home page behind the log in form is submitted, as that page is the one that will have images, content, and all of your other assets.
To start, here is where the scripting option is located on WebPageTest.
This area is where we begin to build our script that will test the scenario we’re interested in. For this example, we’re going to run a script that loads machmetrics.com, and logs into the user dashboard.
Below is the script that accomplishes this (with a replaced email and password). We’re going to need to use navigate, setValue, and submitForm to populate our log in information and submit the form. Just for ease of reading the data later, I also add setEventName so that I can see the data for each step.
The navigate step tells our script which URL to load. We also need to identify the username and password fields of our form and use setValue to put our log-in information in. We can inspect the form to find the name of each form field.
If your form html looks something like this:
<input type=”text” class=”tabInputFields” id=”lgnId1″ value=”” name=”loginId”/>
you can use any of the identifiers you could use any of the identifiers such as – id=lgnId1 , name=loginId or class=tabInputFields.
// Go to Machmetrics.com
// Put our username into the form
setValue name=email [email protected]
// Put our password into the form
setValue name=password yourpassword
// Submit the form
Now we run the script and wait for the data to come in. As you can see, WebPageTest offers an incredible amount of information from our test. You’ll be able to see speed metrics for each of our ‘setEventName’ steps, waterfalls, and even watch a video of each step going through the process.
Testing the speed of a checkout process
Next, let’s walk through the process of selecting a product and checking out on an e-commerce site. If you run any kind of e-commerce site yourself, performance metrics on this process would be invaluable. We’ve written before (How Does Page Load Time Affect Your Site Revenue?) that web performance can have a huge effect on your bottom line, so you need to know how your site is performing through this process.
This script with be similar to the above scenario, but obviously we’ll have additional steps. Mainly, we’ll need to use clickAndWait, a command that instructs our script to click on an element, and wait for the browser to load its subsequent action.
In the below script, we load Menards.com, select a product, add it to the cart, and check out. At this point, we could go even further and log in to our account, adding the above script to this script. For the purpose of this example however, we’ll go to the point where it asks for log in information. Once we inspect our website find the id’s for our product and the buttons to add it to the cart, we can create our script.
// Load URL
// click on product
// Add item to cart
// Click through to cart
// Continue to Checkout
clickAndWait value=Continue to Checkout
Again, after the test is run each step is logged and you can see the performance that our customers would experience if this was our own e-commerce site.
Testing a site with ads disabled
Our final test is arguably the most important, especially for those sites that rely on advertising for revenue. You have probably noticed that some days your site loads super fast, and other days very slow – and the cause for this fluctuation is due to the rotation of ads that your site is serving. This makes it very hard to spot trends in your speed – as your graphs are so noisy with spikes.
However this script isn’t just for ads – it also allows you to measure the performance of your site without 3rd party tags, again removing the noise you see in your trends and giving you a more stable representation of the site speed that you have control over. Taken a step further, this lets you compare between a default test and one with ads disabled, and see the performance cost of adding those additional scripts.
There are a few ways to go about this, depending on whether or not you want to block specific 3rd party requests, or all of them.
To see the performance cost of using Google Fonts, you could run a normal test on your site, and then compare it with the following script using the blockDomains command:
// block google fonts
// navigate to your site with font requests blocked
To do a full block of everything except what is native to your site, you would use the blockDomainsExcept command like so:
// block all ads and 3rd party requests
// navigate to your site with requests blocked
WebPageTest even lets you check the ‘Filmstrip’ box when running your tests. You can then line up tests side by side and compare them. This allows you to see first hand the performance costs of ads or other 3rd party requests.
Scripting is powerful
Some of these types of higher-level functions can be daunting to users. However, they can be incredibly powerful tools when utilized correctly.
If you’re setting up scripting within MachMetrics, it follows the exact same syntax as WebPageTest, and can be entered under the Custom Script checkbox when editing a url:
With great power comes great responsibility – and if you’re having trouble fine tuning a script to work exactly how you’d like it, we’re always here to help.
5 thoughts on “WebPageTest Scripting: Examples for advanced speed testing scenarios”
Hello, I’m a little bit confused about how to run script for webpage test.
as stated in the document https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting
You can test a script in the desktop version by selecting “Run Script” from the File menu.
then what and where is the desktop version? Private instance is a web application. For agent, till now I only successfully installed wptdriver. It has a File menu but doesn’t have “Run Script” item in it. Or is it in the wptagent? But seems it’s just a python script
Hi Olivia – If you’re using WebPageTest.org then see the first screenshot in this article. If you’re using MachMetrics then see the last screenshot. Hope that helps!
i see the script secion in your screenshot above. Sorry I missed it. I will follow your guide. Thanks a lot!
i am able to navigate or perform action on my webpage with java script but jQuery isn’t working. How do i use jQuery for scripting? Should i import any before starting jQuery scripts?
jQuery is not part of the WebPageTest Scripting, you must stick to the commands that are listed by WPT.