Enabling WebPagetest to test complete customer journeys

24.08.2016 von 2020-02-27

iteratec GmbH
Enabling WebPagetest to test complete customer journeys

I love WebPagetest. It’s easy to use and gives us plenty of realistic data about a website’s performance. It even provides a scripting language which allows DOM interaction, JavaScript execution and more during the test. That’s why we built the OpenSpeedMonitor which utilizes WebPagetest for continuous measurements, processes, aggregates, and visualizes the results. The problem with WebPagetest is that it was designed to test only a single page, even with scripting.

Multistep Support

If I want new shoes, I visit my favorite online shop, go for the shoe category, look through the products, take a closer look to some products, maybe use the search engine, and eventually put some in the cart for checkout. These are the steps of my customer journey. During that journey I highly benefit from the browsers built-in cache, as pages are likely to share many static assets like images, styles, and scripts. The web performance I experience during this journey is crucial for how happy I am and will likely decide whether or not I complete my checkout.

To test this journey with WebPagetest, you’d need to run a couple of independent measurements, one for each step of the journey. But as all tests start with a new browser profile and an empty cache, the reported performance will highly differ from what I would experience in reality. To take caching effects into account for one step, the test would need to be a script with multiple steps that only logs the last one:

logData   0
navigate  http://www.bbc.com/
navigate  http://www.bbc.co.uk/search?q=web%20performance
logData   1
navigate  http://www.bbc.com/news/technology-31520413

Can you imagine how tedious it would be to model a complete journey with scripts like this for every single step?

So, wouldn’t it be great to just write a script that measures multiple steps in one run, and therefore model a complete customer journey? Yes it would, and that's why we implemented that feature.

Back to the roots

We actually implemented multistep support some time ago. It all started as a master thesis with implementations in a WebPagetest fork. Over time we improved multistep support and added more features to that fork. But as WebPagetest advanced, our fork eventually grew apart from the main project, making it unable to simply merge back our changes. We ended up in an unfortunate situation where we didn’t profit from WebPagetest improvements, and WebPagetest was still lacking multistep support.

Some weeks ago, we made the decision that this is not the way we want to go further. So we approached the community and started to re-implement multistep support in the official project.

It’s live

This week major work of the official multistep implementation was finished. And guess what? It’s already live on the WebPagetest.org, so everybody can use it! Take this script for example:

setEventName  MainPage
navigate      http://www.bbc.com/
setEventName  SearchResult
navigate      http://www.bbc.co.uk/search?q=web%20performance
setEventName  ArticlePage
navigate      http://www.bbc.com/news/technology-31520413

Pro-Tip: Use setEventName in front of each step for a better overview in the results

It will execute 3 steps navigating on BBC. You will find your results like this:

Just go ahead and take a look at the full results. You will now find waterfall diagrams, breakdown diagrams, screen shots, and even film strips for all steps in the script. Also the XML and JSON result exports include detailed step results, so tools like our OpenSpeedMonitor can import the multistep results for further processing.

But multistep support isn’t limited to “navigate” commands. All script commands ending with “AndWait” will initiate the measurement of a new step. So with “clickAndWait” or “execAndWait” you could also execute some JavaScript and measure the reaction of your single page application.

We’re quite happy that we took this step and are excited to finally get rid of our own branch and use and support the official project again.

And for you there are no excuses left to not optimize your web performance ;-)

Diesen Artikel bewerten
0 Bewertungen (0 %)