How to Use WebPageTest to Test Website Performance

You can’t fix what you can’t measure. That’s especially true when it comes to website speed.

If your site is slow, visitors leave and search engines notice. But the tricky part is knowing what part of your site is slow, not just that something feels off. That’s where WebPageTest comes in.

WebPageTest is a free, open-source tool that runs detailed performance tests on any page on your site. It doesn’t just give you a score. It breaks down every element that loads on a page, shows you exactly what’s causing delays, and gives you clear recommendations for fixing them.

In this guide, you’ll learn how to run your first test, how to read the results, and how to turn what you find into real improvements for your site.

What Is WebPageTest?

WebPageTest is a free performance testing tool that’s become one of the most trusted ways to diagnose website speed problems.

The core idea is straightforward. You give WebPageTest a URL, it loads that page inside a real browser from a server location you choose, and it records everything that happens during the loading process. You get a detailed breakdown of what was loaded, in what order, and how long each step took.

What makes it stand out from simpler tools is depth. You’re seeing a waterfall chart of every network request, a filmstrip of how the page renders frame by frame, Core Web Vitals scores, server response times, and more. A load time score alone doesn’t tell you any of that.

Here’s a quick overview of what the tool includes:

• Tests from 30+ locations around the world
• Support for Chrome, Firefox, Microsoft Edge, and Brave
• Waterfall charts and filmstrip rendering views
• Customizable settings like connection speed and screen resolution
• Core Web Vitals data from real users via Google CrUX
• A free Starter plan with 13 months of test history.

Why You Should Use WebPageTest

Speed tools aren’t in short supply. So why use WebPageTest over something like Google PageSpeed Insights or Pingdom?

The short answer is depth. PageSpeed Insights gives you a score and a list of suggestions. Pingdom shows you load times from a few server locations. WebPageTest does both of those things and then keeps going.

It runs each test multiple times and reports based on the median, which gives you a more reliable result than a single data point.

It also pulls in real-world user data from Google’s Chrome User Experience Report alongside the synthetic test it runs. That means you’re seeing how actual visitors experience your site, not just a controlled simulation.

On top of that, the filmstrip view lets you see exactly what your page looks like at each second during the loading process. That visual layer makes it much easier to understand what the numbers actually mean for your visitors.

How to Set Up WebPageTest

Getting started is quick. Head over to the WebPageTest site, and you can run a test without registering.

That said, creating a free account unlocks the full experience, including your test history, and it doesn’t require payment details. All you need to do is create a free account and login.

On the main screen, you’ll see a simple interface on the homepage with a URL field and a few configuration options to set before you run your first test.

1. Test location. This is the server WebPageTest will use to load your page. Pick one that’s close to where most of your visitors are coming from. Testing from a server that’s geographically far from yours can inflate load times and skew the results.
2. Browser. Chrome is the default and covers the majority of web traffic. Stick with it unless you have a specific reason to test in another.
3. Device type. It’s worth running separate tests for mobile and desktop. Performance can differ significantly between the two, and switching between device types only takes a minute.
4. Advanced Configuration. Click this to unlock additional options, including connection speed simulation, custom screen resolutions, and repeat view testing, which shows how the page loads for a returning visitor with cached assets already in place. You don’t need to touch any of this for a basic test.

Once you’re happy with your settings, paste your URL into the test field and click Start Test. Results usually come back within 10 to 30 seconds.

How to Read WebPageTest Results

The results page is organized into several main sections. Here’s how to work through each one:

Performance Summary

This is the first section you’ll see at the top of your results. WebPageTest evaluates your site across three areas.

Is it quick? How fast does the page load overall.

Is it usable? Does the content shift around after loading, and are there accessibility issues?

Is it resilient? Does the page rely heavily on third-party scripts, and does it support server-side rendering?

Each area uses a visual indicator to show where your site stands. If something is flagged, you can click through to see which element caused the issue and what WebPageTest recommends.

You can also go deeper into these suggestions by clicking the Opportunities tab.

Here, you’ll see a more detailed breakdown of the specific areas where your site could improve and explains why each one matters. Running experiments to model potential optimizations is available on the Pro plan.

Page Performance Metrics

Scroll down, and you’ll reach the Page Performance Metrics section. This is where the core timing data lives. Here’s what each metric is measuring.

Time to First Byte (TTFB) is how long it takes your server to respond after the browser sends a request. Anything under 200ms is solid. Over 600ms points to a problem, usually a slow server, a poorly optimized database, or missing server-side caching.

Start Render is when the browser first starts painting something visible on the screen. A high number here means visitors are sitting in front of a blank page longer than they should be.

First Contentful Paint (FCP) measures when the first piece of visible content appears, whether that’s text, an image, or something else. It’s closely related to Start Render but specifically focused on content.

Speed Index is a composite score that reflects how quickly the visible parts of the page fill in. Lower is better. It’s useful for comparing two versions of the same page because it captures the full visual loading experience.

Largest Contentful Paint (LCP) measures when the largest visible element on the page finishes loading. For most pages, that’s a hero image or a large heading. Google uses LCP as a Core Web Vital, so it has implications for SEO as well as user experience. The target is under 2.5 seconds.

Cumulative Layout Shift (CLS) captures how much the layout moves around as the page loads. If a button shifts right because an image loaded above it, that’s a layout shift. The target is as close to 0 as possible. A high CLS score is frustrating for users and one of Google’s Core Web Vitals.

Total Blocking Time (TBT) shows how long the browser’s main thread is blocked by JavaScript execution, which prevents users from interacting with the page. Aim for under 200ms.

Filmstrip View

Below the metrics (or by clicking the Filmstrip tab), you’ll find a filmstrip showing your page rendering frame by frame over time. This is one of the most useful features in WebPageTest because it makes the data visual.

You can see what your page looks like at each second during the loading process. A long stretch of blank frames, a layout shift, a late-loading image. It all shows up here. It’s much easier to understand what the metrics mean once you can see the actual rendering experience.

Real-World Usage Metrics

This section is different from everything above it. Instead of data from WebPageTest’s synthetic test, you’re looking at real user data from Google’s Chrome User Experience Report.

This shows how actual visitors have experienced your site over the past 28 days. It reports Core Web Vitals at the 75th percentile, meaning the value shown reflects the experience of users where performance tends to be weakest.

Your synthetic test might look great, but if real-world data tells a different story, something is affecting performance for certain users that the lab test isn’t catching. This could be visitors on slower connections, older devices, or locations farther from your server.

How to Read the Waterfall Chart

The waterfall chart is where you can dig into the details of what’s actually happening when your page loads. You’ll find it by clicking the Waterfalls tab at the top of the screen.

Each row in the waterfall represents a single network request, whether that’s an HTML file, a CSS stylesheet, a JavaScript file, an image, a font, or anything else the page needs to load. The horizontal bar shows when the request started, how long it took to connect, how long the server took to respond, and how long the download took.

Some requests block the page from rendering until they finish. WebPageTest marks these with an orange circle and white cross. Render-blocking resources are often the biggest opportunity for improvement, particularly large JavaScript or CSS files loading in the head of your HTML.

Colored vertical lines run across the chart to mark key milestones like First Contentful Paint and Largest Contentful Paint. The requests still loading when those lines appear are usually the ones holding those metrics back.

If you click on any individual row, you’ll get a detailed breakdown of that specific request, including DNS lookup time, connection time, and download time.

Common Issues WebPageTest Reveals

Once you know how to read the results, here are some of the most common problems you’re likely to find.

1. Render-blocking resources

JavaScript and CSS files that load in the <head> of your HTML delay the browser from rendering anything on the page. Deferring or async-loading JavaScript that isn’t needed for the initial render, and inlining or deferring non-critical CSS, are common ways to fix this.

2. Slow server response times

A high TTFB usually means your hosting plan is underpowered, your server isn’t caching effectively, or your database queries are slow. Enabling server-side caching or upgrading your hosting plan are the most direct fixes.

3. Unoptimized images

Large image files are one of the most common culprits for slow load times. WebPageTest flags images that are much larger than the size at which they’re being displayed. Optimizing your images by doing things like compressing images, converting them to WebP, and lazy loading images below the fold all help here.

4. Third-party scripts

Analytics tools, chat widgets, WordPress plugins, ad scripts, and social media embeds add real weight to your page. WebPageTest shows you exactly how much each third-party resource contributes to your overall load time, which makes it easy to decide what’s worth keeping.

5. Missing caching on static assets

If the waterfall shows the same CSS and JavaScript files being fully downloaded on every visit instead of being served from cache, your cache-control headers aren’t configured correctly. Fixing this means returning visitors will load the page much faster.

WebPageTest vs. Other Speed Testing Tools

It’s worth knowing how WebPageTest compares to the tools you might already be using. Here are two of the most common:

Google PageSpeed Insights is the most widely used performance tool because it’s free, fast, and tied directly to Google’s ranking signals. But it only runs a single test, doesn’t let you customize the test environment, and doesn’t provide the waterfall chart depth that WebPageTest does.

Pingdom Tools is useful for quick load time checks from a handful of server locations. It’s beginner-friendly and shows a basic waterfall. But it doesn’t provide real-world user data or the same level of diagnostic detail, and the free version limits the number of locations you can test from.

Running tests across multiple tools occasionally can help you catch things one tool might miss. But if you’re going to settle on one, WebPageTest gives you the most complete picture of the three.

How Often Should You Test?

Testing once and moving on isn’t going to help you. Performance degrades over time as you add plugins, upload media, install new scripts, and traffic grows.

A good rule of thumb is to run a test any time you make a significant change to your site. Installing or updating a plugin, switching themes, adding new scripts, or migrating to a new host are all good triggers. Testing before and after gives you a clear picture of the impact.

Running a monthly test as part of your regular maintenance routine helps you catch gradual regressions before they turn into serious problems.

WebPageTest Pricing

The free Starter plan covers most use cases. You get access to all the core performance metrics, the Opportunities report, and 13 months of test history. No payment information is required, and you can even run a test without creating an account, though signing up gives you access to the full results view.

The Pro plan starts at $18.75 per month, and adds bulk testing, access to more global test locations, priority queue access, the WebPageTest API, no-code experiments, private tests, and dedicated support. If you want to automate testing as part of a development workflow, the API is the main reason to upgrade. For most site owners, the free plan is more than enough.

WebPageTest FAQs

Closing Thoughts: Getting the Most Out of WebPageTest

WebPageTest gives you more insight into your site’s performance than almost any other free tool available. The depth of data can feel overwhelming at first, but once you understand the key sections, it becomes a practical diagnostic tool rather than just a source of scary numbers.

Remember, speed improvements don’t have to happen all at once. Even small changes, like optimizing images or fixing a couple of render-blocking scripts, can have a measurable impact on your load times and user experience.

If you’re on a hosting plan that’s limiting your performance, no matter what optimizations you make, it might be time to look at your setup. At SupportHost, our WordPress hosting plans are built for speed, and migrating is easy if you’re ready to make a switch.

Now over to you. Have you run a WebPageTest on your site yet? What did you find? Share your results or questions in the comments below.