WebPageTest and other speed tools: what each is for
PageSpeed Insights, Lighthouse, DevTools, WebPageTest and field data answer different questions. What each measures, where it runs, and which to use when.
In this guide
The two kinds of data
A lab test loads a page on a test machine under set conditions. It is repeatable and it can show causes. It is not what any real visitor experienced.
Field data is measured on real visits. It shows what happened to real people, over a period, but it does not show causes on its own. See lab and field data.
Every tool below is one or the other, or a mix of both.
The tools
| Tool | Data | Where it runs | Best for |
|---|---|---|---|
| PageSpeed Insights | Lab and field | Google's servers | A quick first look at a public page, with real-visitor numbers when they exist |
| Lighthouse | Lab | Your browser, a script or a build | Findings and a score, repeated and automated |
| Chrome DevTools | Lab (your machine) | Your browser | Finding the cause: requests, long tasks, layout |
| WebPageTest | Lab | Test machines at chosen locations | A filmstrip, a waterfall, comparison, scripted journeys |
| Chrome UX Report | Field | Chrome users, collected by Google | How your site performs for real Chrome visitors over 28 days |
| Real user monitoring | Field | Your own visitors, via your script | Page-level and labeled field data with causes |
PageSpeed Insights
PageSpeed Insights runs Lighthouse on Google's infrastructure and, when your page or site has enough traffic, shows Chrome UX Report data beside it. It is the easiest place to begin, and the field data at the top is the part that counts for the Core Web Vitals. See PageSpeed Insights explained.
Lighthouse
Lighthouse is the open-source lab test behind PageSpeed Insights. You can run it in Chrome DevTools, from the command line, or in a build. It has three modes. Navigation mode analyzes a single page load and is the default. Timespan mode analyzes a period of time, usually with interactions, and does not give an overall score. Snapshot mode analyzes the page in its current state. See the Lighthouse guide and automated tests.
Chrome DevTools
DevTools lets you look inside one load on your own computer: the Network panel for requests, the Performance panel for what the main thread did, and the Lighthouse panel for a report. Use it to find causes once you know where the problem is. See the Performance panel and the Network panel. The Web Vitals Chrome extension has reached the end of its life, and the Chrome team points users to the Performance panel's live metrics instead.
WebPageTest
WebPageTest measures and analyzes the performance of web pages. According to its documentation, its test machines are in locations around the world, and you should pick one close to where your visitors are. You choose a browser. The documentation lists Chrome, Firefox, Edge, Android and iOS among them, though not every location offers every browser, and it recommends starting with Chrome because it reports the most information. It also offers emulated mobile devices, which simulate constraints such as a slower processor using Chrome's Device Mode.
Its results page starts with a summary and the main metrics: time to first byte, start render, First Contentful Paint, Speed Index, Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time and page weight. For a test with repeat runs it shows the median run and the repeat view. Where the Chrome UX Report has data, it shows that too. Below that are:
- A filmstrip, a set of screenshots of the page as it loaded, which you can also use to compare runs side by side. Beneath the filmstrips there are waterfalls with a line synced to the screenshots, so you can see what the browser was doing at each visual moment.
- A waterfall of requests and connections for each run.
- Opportunities and experiments, a list of diagnostics, with experiments that test a fix. The documentation says most experiments are a premium feature.
- An optimization page with grades for a set of basic checks, such as compression and caching. Treat these grades as hints. The documentation behind them is older than most of the tools in this guide.
#### Scripts for multi-step journeys
A page that requires a login, or a cart, cannot be tested with a bare URL. WebPageTest has a scripting language for this. A script can navigate, set field values, click, and run JavaScript while a test is running. The documentation's login example turns logging off while it signs in, so the login page does not appear in the results, and turns it back on before the page being measured. Use it to test a signed-in page or the page after an interaction. Keep real passwords out of scripts, and use a test account.
Because the service changes, check its site for what is currently free, which test locations exist, and how many tests you can run.
The Chrome UX Report and real user monitoring
These are field data. The Chrome UX Report is collected by Google from Chrome users and reported over a 28-day window. Real user monitoring is data you collect from your own visitors. See the Chrome UX Report and real user monitoring.
Choosing a tool
Ask what you need to know:
- "Do I have a problem?" Start with PageSpeed Insights, and look at the field data first.
- "What is causing it?" Use DevTools for one load, or Lighthouse's list of findings.
- "How does it look to a visitor in another country or on a phone?" WebPageTest, with a nearby location and a mobile profile. Then a real phone. See testing on real phones.
- "Is it getting slower over time?" A budget with Lighthouse CI, or a scheduled routine. See automated tests and budgets.
- "Did my fix work for real visitors?" Field data, over weeks. See how to test speed changes safely.
A small toolkit
For most sites, five habits are enough:
- The free audit or PageSpeed Insights for a first check.
- DevTools for the cause on one page.
- A comparison tool like WebPageTest when you need a filmstrip, another location or a scripted journey.
- The Chrome UX Report in PageSpeed Insights each month.
- Your own monitoring if you need page-level answers, and a build check if you have a build.
Mistakes to avoid
- Comparing numbers from different tools. Each uses different hardware, locations and settings. Compare like with like.
- Testing once. Repeat and take a median.
- Using one location. Test from where your visitors are.
- Chasing the grade. A score is a summary. The findings and the field data matter.
- Forgetting the signed-in pages. Visitors who buy or log in see pages that a bare URL test never loads.
Check your own page
Run the free audit, then run the same URL in a second tool, such as WebPageTest from a location near your visitors. Compare the biggest findings. When the tools agree, the problem is real. When they disagree, check the settings: location, device, throttling and cache.
Sources
- Quick start guide and Scripting in the WebPageTest documentation: locations, browsers, emulated devices, the results pages and scripts.
- User flows in Lighthouse: the navigation, timespan and snapshot modes.
- Web Vitals extension: the end of the extension and the move to DevTools.
- Chrome UX Report methodology: what the report covers and for how long.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Core Web Vitals · Book a call