You can use SpeedCurve to test pages that are part of a complex user flow, for example going through the checkout process of an e-commerce site.

The easy way: Create a stand-alone page

By far the easiest way to test pages that are part of user flows is to create a stand-alone page for the sole purpose of performance testing. This could be a checkout page with some hard-coded items in the shopping cart, or a test user account page that doesn't require authentication.

The main benefit to this approach is that it doesn't require writing complex WebPageTest scripts. The downside is that you need to invest some time in building the pages.

The other way: Use WebPageTest scripting to simulate user input

If you're a SpeedCurve Enterprise customer, you can use WebPageTest scripts to simulate a user navigating through your website. You can read about how to add scripts to your URLs here: Adding WebPagetest scripts to URLs.

Below are some example scripts that various user flows. They have been annotated with comments to explain what each step is doing, and you can find more information about scripting in the WebPagetest scripting documentation. Before using these examples, it's important to note a couple of things:

  • While WebPageTest supports commands like click, setValue, and submitForm, we prefer using the exec command to run JavaScript on the page. This is because it is easy to debug exec commands by running the JavaScript directly in your browser console.
  • When debugging the WebPageTest scripts, we recommend removing the logData commands and running the scripts on https://www.webpagetest.org/ so that you can see where exactly the script is failing.

Note: Despite loading multiple pages, these user flow scripts will only count as one check from your SpeedCurve budget. 

Example 1: Simulating simple navigation 

// Turn data logging off to ensure that no performance metrics are
// collected until we navigate to the final page.
logData 0

// Navigate to the first page of the user flow. In this case, the
// index page of the SpeedCurve blog.
navigate https://speedcurve.com/blog/

// Clear the screen so that visual metrics (like Start Render) are
// calculated correctly.
exec document.body.style.display = 'none'

// Turn data logging back on. Performance metrics will be collected
// from this point onwards.
logData 1

// Navigate to the latest blog post.
execAndWait document.querySelector('.post-title a').click()

Example 2: Simulating a checkout process

// Turn data logging off to ensure that no performance metrics are
// collected until we navigate to the final page.
logData 0

// Navigate to the first page of the user flow. In this case, a
// product page of a made-up website.
navigate https://shop.speedcurve.com/products/1234

// Add an item to the user's cart
exec document.querySelector('.add-to-cart').click()

// Go to the cart page
navigate https://shop.speedcurve.com/cart

// Begin the checkout process
exec document.querySelector('.checkout-as-guest').click()

// You can add more steps for completing the user flow here.
// We recommend completing user actions with the "exec" command
// because it is easier to debug in your own browser.

// Before loading the page that you want to test, clear the
// screen so that visual metrics (like Start Render) are calculated
// correctly.
exec document.body.style.display = 'none'

// Turn data logging back on. Performance metrics will be collected
// from this point onwards.
logData 1

// Navigate to the checkout page.
execAndWait document.querySelector('.checkout-submit').click()

Example 3: Simulating Ajax or SPA navigation

In Example 1, the script clears the current page before navigating to the next page. This helps WebPageTest to calculate the visual metrics correctly. This technique needs to be modified slightly for single page applications (SPA) and pages that use Ajax.

// Turn data logging off to ensure that no performance metrics are
// collected until we navigate to the final page.
logData 0

// Navigate to the first page of the user flow. In this case, the
// index page of the SpeedCurve blog.
navigate https://speedcurve.com/blog/

// Clear the screen so that visual metrics (like Start Render) are
// calculated correctly.
exec document.body.style.display = 'none'

// Turn data logging back on. Performance metrics will be collected
// from this point onwards.
logData 1

// Load the next page with Ajax. Show the document body immediately
// after the click handler so that the page isn't blank after the
// Ajax call finishes.
execAndWait document.querySelector('.next-page').click(); document.body.style.display = 'block'

The reason this is different is because in Example 1, we blank the screen by setting the body display to "none". The browser automatically un-blanks the screen when it navigates to the next page. However, with a SPA, the browser doesn't automatically un-blank the screen because there is no navigation occurring. In this case, we un-blank the screen as soon as we trigger the Ajax call by setting the body display back to "block".

Important caveats

Browser cache

Unscripted tests in SpeedCurve load a page with a completely empty cache. However when you run a scripted test that simulates user flow, the browser cache will be filled as the browser performs actions and loads different pages. This is often the desired behaviour, since a real user would also have a full cache. However, in some cases you may still want to test the performance of a page with an empty cache. In these cases, you can use the clearCache command to clear the browser cache at any point. Note that the clearCache command is only supported in Chrome.

Did this answer your question?