Blog Post

Introducing Opportunities & Experiments on WebPageTest: Take the Guesswork out of Performance

Published
June 1, 2022
#
 mins read
By 

in this blog post

As many of you will know, Catchpoint and WebPageTest joined forces 18 months ago with the goal of building stronger alignment across the IT org to ensure performance issues can be caught in QA, staging and development, not just once new features are released to production.

Today we are excited to launch a set of new, powerful features and functionality for all users of WebPageTest to help make it faster and easier for you and your teams to make sense of your website’s performance, the opportunities for improvement, and, critically, how significant those opportunities are.

WebPageTest has always been great at providing in-depth and accurate information about how your site performs across all major browsers, but we’ve always stopped just short of giving you specific advice on what to do. One of the goals that has guided our changes to WebPageTest in the past few years is to close the gap between “uh oh, something’s wrong” to “I know what I need to do to fix this.”

Sit back and grab a cup of coffee, because there’s a lot to unpack here.

Opportunities for improvement

One of the features we’re launching today for all WebPageTest users is our new set of Opportunities: helpful, actionable advice on what opportunities there are to improve your site’s speed, usability and resilience.  

Performance summary example of a WebPageTest with helpful and actionable advice.

Opportunities are broken into three categories:

  • Opportunities to improve your site’s speed
  • Opportunities to improve your site’s usability
  • Opportunities to improve your site’s resiliency

What does this mean? It means WPT is moving beyond the concept of performance simply as a number to encompass usability and resilience. At Catchpoint we are passionate about creating opportunities across our solutions for more aligned workflows among the different groups responsible for delivering better performance. This new feature in WebPageTest moves us closer to working across the entire IT org on the application lifecycle.  

As Catchpoint’s VP of Operations, Tony Ferrelli, says, “SRE is about partnership with the development teams as they build the applications that grow the business. It’s really important that the teams work together to make sure that all the core operational principles (availability, reliability, scalability and performance) are accounted for and that you can measure them.”

Opportunities in WebPageTest marks an important step towards that. We’re also surfacing insights beyond performance, usability and resilience. We’ve provided a security score, powered by Snyk, for a while now and have seen how even folks who were testing for performance were also motivated to improve their security. For the first time, we’re also including information about the accessibility of your site directly in every test result. Each page run through WebPageTest is tested by Axe for WCAG 2.0 Level AA compliance, and any violations are now reported in our new opportunities, under the Usable category.

Example of a WebPageTest detecting accessibility issues and advice on how to improve accessibility.
“There's a ton of information that WebPageTest gives you out of the box, but how do we make that easier for folks who are just getting started? How do we make sure that our power users are also getting valuable insights? How do we make sure that those results are actionable? How do we make sure that you can bake performance into your DevOps process, from development to the CI/CD process, to post development and debugging?
And above all how can we make it easier and effective for you to test without having to code and/or go through different chains of command?  
These are some of the questions we set out to answer as a team and we’re very excited about the possibilities that WebPageTest will help you deliver, starting today.” Tim Kadlec, Director of Developer Experience Engineering, WebPageTest

Introducing no-code Experiments

Being able to see what opportunities might be available is one thing, but equally important, and frequently more challenging, is being able to see how impactful certain opportunities may or may not be in improving your user experience. So, alongside Opportunities, we’re launching No-Code Experiments: a brand new feature to let you test optimizations on your site without you ever having to touch your site’s code.

To be blunt: we think this one is a bit of a game-changer.

One of the common issues we’ve heard from teams is that while they can figure out a list of potential optimizations, they have no idea how much of a difference they’re going to make without putting in some serious work to prototype potential solutions. The result is often weeks, or even months, of wasted effort on an optimization that ends up having little or no impact. A waste for not only devs, but DevOps, SREs and ITOps striving to deliver the most performant, resilient site and services.

We can, and need to, do better if we want to make improving the web’s performance more achievable.

Wherever applicable, each opportunity will have an experiment (or several) associated with it.  

For example, if we see you are loading render-blocking JavaScript, we point that out in an opportunity for improvement, but we also offer Experiments to see what would happen if you deferred, in-lined or loaded those scripts asynchronously.

Example of 3 Javascript files blocking page rendering after a test and advice if the user decides to defer.

If you want to try any of those Experiments, you select the box and you can immediately re-run the test with that optimization applied to all the resources causing the bottleneck (or just a few of them, if you prefer). You don’t have to touch a line of code: we apply the optimizations dynamically in our sandbox environment (alongside a control test without the experiment applied) and provide a report on how impactful the optimization ends up being, helping to make it much easier for you to prioritize what to tackle first.

Example of experiment results after WebPageTest and measured metrics.

For folks who want to run Experiments beyond the ones we provide out of the box, we also provide the ability to create Custom Experiments to do everything from Find and Replace text, to applying delivery optimizations to individual requests, to injecting HTML into your page’s head or body. For example, what if you could see the impact a third-party tag will have on your performance before you add it to your site? You can use WebPageTest Custom Experiments to inject the tag in your HTML and measure the impact right away.  We think this will be a great way to understand the true impact of third-party resources and optimize accordingly. Additionally, with Custom Experiments, we know our customers who rely on us for API Observability will relish the chance to explore this further.

Example of 'create experiments' option on WebPageTest and using this to inject the tag in your HTML being able to measure the impact instantly.

To help you get a feel for how Opportunities and Experiments work, WPT has built The Metric Times: your source of performance anti-patterns since 2022. The Metric Times features a bevy of anti-patterns just waiting to be addressed and we’ve unlocked all Experiments for free on any test of the page.  

Experiments are one of several features we’re rolling out under our new WebPageTest Pro plans. WebPageTest Pro also provides several other features and functionality that have long been requested from our power users: bulk testing functionality, new premium test locations, high-priority test queuing, private tests and API access.

“How about we move performance to the left and help teams catch performance issues before they get released to production? I really believe deep down inside that performance is a culture. It’s not just an afterthought. It should be the most important feature of any product.” Mehdi Daoudi, CEO and co-founder, Catchpoint

We’re just getting started

We are so excited about Opportunities, Experiments and the bevy of other features being rolled out today, and the initial feedback has been outstanding. But we’re just getting started. And we are so excited about the overall experience we are building with our solutions for all our Catchpoint users.  

To get started today, sign up for a WebPageTest account. And, as always s, if you have feedback on how we can improve these new features, or new Opportunities and Experiments you would find helpful, let us know.  

Have fun experimenting!

Related Resources

https://blog.webpagetest.org/posts/introducing-opportunities-and-experiments/

https://www.catchpoint.com/blog/webpagetest-and-catchpoint

https://www.catchpoint.com/blog/webpagetest-and-catchpoint-mehdi-jeena

https://www.catchpoint.com/blog/a-year-of-webpagetest-and-catchpoint-a-q-a-with-dritan-suljoti-and-jeena-james

https://www.catchpoint.com/blog/a-year-of-webpagetest-and-catchpoint-a-q-a-with-tim-kadlec-and-jeena-james

As many of you will know, Catchpoint and WebPageTest joined forces 18 months ago with the goal of building stronger alignment across the IT org to ensure performance issues can be caught in QA, staging and development, not just once new features are released to production.

Today we are excited to launch a set of new, powerful features and functionality for all users of WebPageTest to help make it faster and easier for you and your teams to make sense of your website’s performance, the opportunities for improvement, and, critically, how significant those opportunities are.

WebPageTest has always been great at providing in-depth and accurate information about how your site performs across all major browsers, but we’ve always stopped just short of giving you specific advice on what to do. One of the goals that has guided our changes to WebPageTest in the past few years is to close the gap between “uh oh, something’s wrong” to “I know what I need to do to fix this.”

Sit back and grab a cup of coffee, because there’s a lot to unpack here.

Opportunities for improvement

One of the features we’re launching today for all WebPageTest users is our new set of Opportunities: helpful, actionable advice on what opportunities there are to improve your site’s speed, usability and resilience.  

Performance summary example of a WebPageTest with helpful and actionable advice.

Opportunities are broken into three categories:

  • Opportunities to improve your site’s speed
  • Opportunities to improve your site’s usability
  • Opportunities to improve your site’s resiliency

What does this mean? It means WPT is moving beyond the concept of performance simply as a number to encompass usability and resilience. At Catchpoint we are passionate about creating opportunities across our solutions for more aligned workflows among the different groups responsible for delivering better performance. This new feature in WebPageTest moves us closer to working across the entire IT org on the application lifecycle.  

As Catchpoint’s VP of Operations, Tony Ferrelli, says, “SRE is about partnership with the development teams as they build the applications that grow the business. It’s really important that the teams work together to make sure that all the core operational principles (availability, reliability, scalability and performance) are accounted for and that you can measure them.”

Opportunities in WebPageTest marks an important step towards that. We’re also surfacing insights beyond performance, usability and resilience. We’ve provided a security score, powered by Snyk, for a while now and have seen how even folks who were testing for performance were also motivated to improve their security. For the first time, we’re also including information about the accessibility of your site directly in every test result. Each page run through WebPageTest is tested by Axe for WCAG 2.0 Level AA compliance, and any violations are now reported in our new opportunities, under the Usable category.

Example of a WebPageTest detecting accessibility issues and advice on how to improve accessibility.
“There's a ton of information that WebPageTest gives you out of the box, but how do we make that easier for folks who are just getting started? How do we make sure that our power users are also getting valuable insights? How do we make sure that those results are actionable? How do we make sure that you can bake performance into your DevOps process, from development to the CI/CD process, to post development and debugging?
And above all how can we make it easier and effective for you to test without having to code and/or go through different chains of command?  
These are some of the questions we set out to answer as a team and we’re very excited about the possibilities that WebPageTest will help you deliver, starting today.” Tim Kadlec, Director of Developer Experience Engineering, WebPageTest

Introducing no-code Experiments

Being able to see what opportunities might be available is one thing, but equally important, and frequently more challenging, is being able to see how impactful certain opportunities may or may not be in improving your user experience. So, alongside Opportunities, we’re launching No-Code Experiments: a brand new feature to let you test optimizations on your site without you ever having to touch your site’s code.

To be blunt: we think this one is a bit of a game-changer.

One of the common issues we’ve heard from teams is that while they can figure out a list of potential optimizations, they have no idea how much of a difference they’re going to make without putting in some serious work to prototype potential solutions. The result is often weeks, or even months, of wasted effort on an optimization that ends up having little or no impact. A waste for not only devs, but DevOps, SREs and ITOps striving to deliver the most performant, resilient site and services.

We can, and need to, do better if we want to make improving the web’s performance more achievable.

Wherever applicable, each opportunity will have an experiment (or several) associated with it.  

For example, if we see you are loading render-blocking JavaScript, we point that out in an opportunity for improvement, but we also offer Experiments to see what would happen if you deferred, in-lined or loaded those scripts asynchronously.

Example of 3 Javascript files blocking page rendering after a test and advice if the user decides to defer.

If you want to try any of those Experiments, you select the box and you can immediately re-run the test with that optimization applied to all the resources causing the bottleneck (or just a few of them, if you prefer). You don’t have to touch a line of code: we apply the optimizations dynamically in our sandbox environment (alongside a control test without the experiment applied) and provide a report on how impactful the optimization ends up being, helping to make it much easier for you to prioritize what to tackle first.

Example of experiment results after WebPageTest and measured metrics.

For folks who want to run Experiments beyond the ones we provide out of the box, we also provide the ability to create Custom Experiments to do everything from Find and Replace text, to applying delivery optimizations to individual requests, to injecting HTML into your page’s head or body. For example, what if you could see the impact a third-party tag will have on your performance before you add it to your site? You can use WebPageTest Custom Experiments to inject the tag in your HTML and measure the impact right away.  We think this will be a great way to understand the true impact of third-party resources and optimize accordingly. Additionally, with Custom Experiments, we know our customers who rely on us for API Observability will relish the chance to explore this further.

Example of 'create experiments' option on WebPageTest and using this to inject the tag in your HTML being able to measure the impact instantly.

To help you get a feel for how Opportunities and Experiments work, WPT has built The Metric Times: your source of performance anti-patterns since 2022. The Metric Times features a bevy of anti-patterns just waiting to be addressed and we’ve unlocked all Experiments for free on any test of the page.  

Experiments are one of several features we’re rolling out under our new WebPageTest Pro plans. WebPageTest Pro also provides several other features and functionality that have long been requested from our power users: bulk testing functionality, new premium test locations, high-priority test queuing, private tests and API access.

“How about we move performance to the left and help teams catch performance issues before they get released to production? I really believe deep down inside that performance is a culture. It’s not just an afterthought. It should be the most important feature of any product.” Mehdi Daoudi, CEO and co-founder, Catchpoint

We’re just getting started

We are so excited about Opportunities, Experiments and the bevy of other features being rolled out today, and the initial feedback has been outstanding. But we’re just getting started. And we are so excited about the overall experience we are building with our solutions for all our Catchpoint users.  

To get started today, sign up for a WebPageTest account. And, as always s, if you have feedback on how we can improve these new features, or new Opportunities and Experiments you would find helpful, let us know.  

Have fun experimenting!

Related Resources

https://blog.webpagetest.org/posts/introducing-opportunities-and-experiments/

https://www.catchpoint.com/blog/webpagetest-and-catchpoint

https://www.catchpoint.com/blog/webpagetest-and-catchpoint-mehdi-jeena

https://www.catchpoint.com/blog/a-year-of-webpagetest-and-catchpoint-a-q-a-with-dritan-suljoti-and-jeena-james

https://www.catchpoint.com/blog/a-year-of-webpagetest-and-catchpoint-a-q-a-with-tim-kadlec-and-jeena-james

This is some text inside of a div block.

You might also like

Blog post

Performing for the holidays: Look beyond uptime for season sales success

Blog post

Catch frustration before it costs you: New tools for a better user experience

Blog post

Did Delta's slow web performance signal trouble before CrowdStrike?