WebPageTest

TL;DR — WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. is a free tool that loads your page on a real browser in a real location and shows you exactly what happened as it loaded — every file it downloaded, in what order, and a frame-by-frame video of the page appearing. It’s the tool you use when PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. says a page is slow but you want to see why. It’s not a Google product, and its scores don’t affect your rankings — it’s a diagnosis tool.

What WebPageTest is

Most speed tools give you a number. WebPageTest gives you a story — a detailed, step-by-step picture of how your page loaded.

You go to webpagetest.org, type in a URL, pick where in the world to test from and on what kind of device and connection, and hit start. A real browser on a real machine loads your page, and WebPageTest records everything: every image, script, and font it fetched, how long each took, and a filmstrip — an actual frame-by-frame set of screenshots of the page appearing on screen.

It’s free and open source. It was built by a developer named Patrick Meenan back in 2008, and a company called Catchpoint bought it in 2020 — but the free public version at webpagetest.org is still there for anyone to use.

Why you’d use it instead of PageSpeed Insights

PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (Google’s tool) is great at telling you that a page is slow and giving you a score. WebPageTest is better at telling you why and where. If PSI says “reduce render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint.,” WebPageTest shows you the exact file that’s blocking, at what second, in a chart you can read like a timeline.

The other thing people get wrong: WebPageTest scores are not a ranking factor. Google ranks partly on how fast real visitors experience your site (that’s called “field dataPerformance metrics captured from real users, not lab tests.,” and it comes from actual Chrome users). WebPageTest is a “lab” test — one controlled run on one machine. It’s for finding and fixing problems, not for the number Google actually sees.

The two views most people start with

• The waterfall. A chart with one row per file your page loaded, stacked in the order they came in. Long bars and files stacked at the start are usually where your slowness lives.
• The filmstrip. A row of screenshots showing the page painting in over time. You can literally watch the moment your main content shows up — or the moment something jumps around on the page.

Want the full version — the connection view, the exact recipe I use to hunt down layout shiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., how it compares to LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., and how I use it for technical SEO? Switch to the Advanced tab.

TL;DR — WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. is a free, open-source lab (synthetic) performance tool: a URL, a real distributed test location, a browser, and a network profile in, deep diagnostics out — waterfall (render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. flags, sequencing), filmstrip/video (frame-by-frame, with a Highlight Layout ShiftsCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. option for CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.), connection view (DNS/TCP/TLS/TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.), and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. frame by frame. Patrick Meenan built it in 2008 (an internal AOL tool); Catchpoint acquired it in 2020; the code stays open under the Polyform Shield license. The accuracy spine: it produces lab data, not field dataPerformance metrics captured from real users, not lab tests., so it does not feed Google’s CWV ranking signal (that’s real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.). It’s a diagnostic, not the score Google sees — and it’s not a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. competitor, because you can run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. inside it. Reach for it when PageSpeed Insights tells you a page is slow but not why or where in the load.

What it actually is

Every WebPageTest result is one configured run: a URL, tested from a specific location, on a specific browser and device, over a specific connection profile, at a specific moment. It’s not a universal measurement of “how fast your site is” — it’s evidence from that run, and it needs to be read as such.

Within that framing, WebPageTest is the deep-diagnostic tool in the web-performance toolbox. web.dev, Google’s own developer site, frames it well: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (web.dev, “How To Think About Speed Tools”)

Its “audit” page adds the SEO-adjacent angle: “WebPagetest will also check static-content cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., time to first byte, and if your site makes effective use of CDNs.” (web.dev, “Audit performance”)

Where the sibling tools in this cluster — Google Lighthouse, PageSpeed Insights, and the Chrome UX Report (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — give you a score or a pass/fail, WebPageTest gives you the request-by-request, frame-by-frame evidence underneath the score.

A brief history — and a genuinely odd footnote

Patrick Meenan created and open-sourced WebPageTest in 2008; it began life as an internal testing tool at AOL. Catchpoint acquired it in 2020. The About page tells the origin story directly: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” The stated mission there is blunt: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (webpagetest.org/about)

Here’s the odd footnote worth naming: Meenan now works at Google on Chrome and web performance. And yet Google’s own official Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. tools page — web.dev/articles/vitals-tools, the exact page Search Central’s Core Web Vitals doc links to as “the different tools that can help you measure and report Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors.” — does not mention WebPageTest. It lists CrUX, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance., Lighthouse, the DevTools Performance panel, the web-vitals JS library, and Lighthouse-CI. The tool built by the person who now works there is absent.

Read that carefully, though: it is not a signal that WebPageTest is deprecated or unendorsed. Google curates its own-product tool list; a third-party open-source tool simply isn’t on it. Other web.dev pages (speed-tools, performance-audit-tools) reference WebPageTest positively. It’s a curation gap, not a verdict on the tool.

Lab vs. field — the distinction that matters most

This is the accuracy spine of the whole topic, and it’s the sibling of the lab-vs-field point that runs through the whole web performance tools cluster.

WebPageTest runs lab (synthetic) data: a controlled, repeatable test on a machine you configure, at a moment you choose. That is a different animal from field data — the real-user Chrome UX Report (CrUX) measurements that Google Search actually uses for the Core Web Vitals ranking signal, and that surface in PageSpeed Insights and Search Console.

So, plainly:

• A WebPageTest run does not feed Google’s ranking signal. It measures the same metrics Google cares about (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLS), but the number Google ranks on comes from CrUX field data, not from any lab run — not WebPageTest’s, not PSI’s lab section, not Lighthouse’s.
• WebPageTest is for diagnosis: reproducing a problem, isolating it, and confirming a fix in a fast, controlled loop. Field data (CrUX) is the slow, authoritative confirmation that real users felt the improvement — see Core Web Vitals for how that ranking signal works.

Put plainly, a WebPageTest result is not — and cannot substitute for — CrUX field data, real-user traffic numbers, or a Google Search ranking or page-experience outcome. Those are separate datasets that need their own evidence; a fast synthetic run is not proof any of them moved.

If you only take one thing from this page: WebPageTest tells you what to fix; CrUX tells you whether Google’s ranking signal moved.

How to run a basic test

The core flow is deliberately simple:

1. URL. The public page you want to test (it has to be publicly reachable).
2. Test location. WebPageTest runs on physically distributed real machines around the world — pick one near your audience, because distance and network conditions change the result.
3. Browser / device. Chrome gives you the most data. You can also emulate mobile devices.
4. Connection profile. A throttled network (e.g. a slow mobile connection) so you’re testing realistic conditions, not your office fiber.
5. Repeat runs. This is the one beginners skip. Performance varies run to run (network jitter, server load, CPU contention), so WebPageTest runs multiple tests and reports a median. Never trust a single run — read the median. Just keep in mind the median is still a synthetic sample from your chosen configuration, not a population-level measurement of what real visitors experience — that’s what field (CrUX) data is for.

Every one of those settings is part of the experiment, not incidental detail. If you’re comparing two tests — before/after a fix, or your site against a competitor’s — the comparison only means something when you record the settings and hold them constant: same location, same browser, same connection profile, same cache state (first view vs. repeat view), and roughly the same run count and time window. Change any of those between runs and you can easily mistake test-configuration drift for a real performance difference.

Reading the results

The waterfall chart

The waterfall is a request-by-request timeline: one row per resource, in load order, each bar showing DNS/connect/TLS/wait/download phases. It flags render-blocking resources, shows redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. as extra hops, and makes it obvious when a handful of resources at the top are gating everything behind them. This is where “reduce render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint.” stops being an abstraction and becomes “that CSS file, at that second.”

The connection view

Grouped by connection rather than by request, this view exposes DNS lookup, TCP connect, TLS negotiation, and time to first byte (TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.) per host. It’s the fastest way to see whether your slowness is server/network-side (a slow TTFB, too many separate connections) versus content-side.

The filmstrip / video view — and my CLS-hunting recipe

The filmstrip is a strip of screenshots of the page painting over time; the video view plays it back. It’s how you see — not infer — when your main content appears, and when something on the page jumps.

This is the WebPageTest feature I lean on most, and I’ve walked through it repeatedly in talks and in my Ahrefs Core Web Vitals guide. For hunting down Cumulative Layout Shift, the exact recipe I use: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” That turns the filmstrip into a high-resolution timeline where a shift is impossible to miss. In the real example from that guide, the culprit was a font swap — “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” Web fonts, late-loading images, and injected ads are the usual CLS suspects, and the filmstrip catches them visually in the act.

One caution: a resource finishing loading in the waterfall at the same moment the filmstrip shows a jump is strong circumstantial evidence, not proof — it’s a hypothesis. Confirm it by isolating the suspect (block that domain/request, or defer it) and re-running the same configuration; if the shift disappears, you’ve confirmed the cause instead of just correlating two timelines.

Core Web Vitals, frame by frame

WebPageTest reports LCP, CLS, and (with real interaction) INP alongside TTFB, FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital., and Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. — and lets you see where in the load each one happened rather than just a final value. Where CrUX field data is available, it can be shown alongside the lab results, but the deep diagnostics are the lab run.

Advanced features

• Scripting / multi-step flows. Test pages behind a login, or a cart/checkout flow — script the steps so WebPageTest measures a real journey, not just a cold homepage. Control and write down what the script depends on: the test account/credentials used, what state the account is in, any dynamic content on the page, and your API quota — an undocumented script is as hard to compare run-to-run as an undocumented manual test.
• Domain / request blocking. Block a specific third-party domain and re-run to measure exactly how much that chat widget or ad script is costing you. This is something PSI simply can’t do.
• Lighthouse inside WebPageTest. “WebPageTest vs. Lighthouse” is a false dichotomy — you can run a Lighthouse audit from within WebPageTest. Worth being precise about what that means: the Lighthouse audit is its own distinct, versioned report — its own 0–100 score and its own audit list — generated inside the broader WebPageTest test session, not merged into WebPageTest’s native waterfall/filmstrip metrics. As I put it in the Ahrefs guide, most speed tools use Lighthouse under the hood: “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (Ahrefs — Core Web Vitals)
• Opportunities & Experiments. A no-code, before/after HTML-change comparison feature that let you compare two states of a page without touching production — introduced around 2022, per contemporaneous coverage by Detlef Johnson at Search Engine Land (that specific article has since been retired from the site, and I couldn’t independently re-confirm the feature’s current name or availability against a live WebPageTest session during this update pass — worth a fresh check before you build a workflow around it by that name).
• API / automation and private instances. There’s an API for programmatic testing, and because the code is open source, you can stand up your own private instance.

Using WebPageTest for technical SEO

This is the angle most WebPageTest guides skip, and it’s why the tool belongs in a technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own.’s kit:

• Test as GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.. You can set a Googlebot user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and watch how render-blocking JS behaves — a useful approximation (not a perfect replica) of how Google’s renderer might experience the page. MobileMoxie’s technical-SEO WebPageTest guide frames the SEO value well: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., caching concerns, security information, and more.”
• Audit redirect chains. The waterfall exposes every redirect hop, so a bloated redirect chain (each one a round trip) is visible instead of hidden.
• Check caching and CDN effectiveness. Per web.dev above, WebPageTest checks static-content caching, TTFB, and CDN usage — the plumbing that governs how fast bots and users alike get your bytes.
• Diagnose JS-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. problems. If content only appears after JavaScript runs, the filmstrip and waterfall show you when (and whether) it painted.
• Before/after evidence for stakeholders. A side-by-side filmstrip of the current page versus a proposed fix is a far more persuasive artifact for a client or an eng team than a Lighthouse number that dropped by six points.

Pricing and access

The free public service at webpagetest.org has historically offered on the order of hundreds of test runs a month, plus a free API key with daily limits. A paid WebPageTest Pro tier unlocks more API volume, private tests, and priority in the test queue. And because the whole thing is open source under the Polyform Shield license — Catchpoint’s framing is that “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (webpagetest.org/about) — you can also self-host a private instance.

Honest limitations

• Learning curve. The UI is dense; a waterfall is intimidating before it’s useful.
• Account needed for saved/private results. Casual one-off tests are open, but saving and private testing want an account.
• It diagnoses, it doesn’t remediate. WebPageTest shows you the problem in exquisite detail; it won’t hold your hand through the fix the way some scoring tools try to.
• Single-run variability. One run can mislead. Use multiple runs and read the median — the tool defaults to this for a reason.

A note on Bing

There’s no Bing or Microsoft documentation that positions WebPageTest as a ranking input or first-party recommendation. Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. has its own Site Scan and speed-related recommendations, but nothing WebPageTest-specific — and Core Web Vitals itself remains primarily a Google construct. (Don’t confuse WebPageTest with Bing’s own bing.com/tools/speedtest, which is a network speed test, not a page performance tool.)

Where this sits

This is the deep-diagnostic member of the web performance tools cluster. Its siblings each own a different job: Google Lighthouse is the lab audit that produces the 0–100 score (and that many other tools run under the hood); PageSpeed Insights shows CrUX field data and a Lighthouse lab run in one UI; the Chrome UX Report (CrUX) is the real-user field dataset Google actually ranks on. For the metrics all of these measure and the thresholds Google uses, start at the Core Web Vitals hub. For the whole pipeline these tools sit within, see the web performance cluster.

AI summary

A condensed take on the Advanced version:

• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. = the deep-diagnostic, lab-based performance tool. Free and open source; created by Patrick Meenan in 2008 (an internal AOL tool), acquired by Catchpoint in 2020, code under the Polyform Shield license.
• Every result is one configured run — a URL, a location, a browser, a connection profile, a moment in time — not a universal measurement. Comparisons only mean something when you record those settings and hold them constant.
• Lab, not field. It produces synthetic lab data and does not feed Google’s Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. ranking signal — that’s real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (seen in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.). A WebPageTest run doesn’t establish real-user traffic or a Search ranking/page-experience outcome either — it’s for diagnosis, not the number Google ranks on.
• The flow: URL → real distributed test location → browser/device → throttled network → multiple repeat runs, read the median (never a single run — though even the median is still a synthetic sample, not field dataPerformance metrics captured from real users, not lab tests.).
• Signature views: waterfall (request-by-request, render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. flags, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. chains), filmstrip/video (frame-by-frame; a Highlight Layout ShiftsCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. option for CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.), connection view (DNS/TCP/TLS/TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.), and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. frame by frame. Aligning a waterfall event with a filmstrip frame is a strong hypothesis, not proof — confirm it by isolating the resource and re-testing.
• CLS recipe: Filmstrip View → Highlight Layout Shifts on, Thumbnail Size Huge, Thumbnail Interval 0.1s — the way to catch a font-swap or late-image shift in the act.
• Not a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. competitor — you can run a Lighthouse audit from within WebPageTest, but it’s its own distinct, versioned report (own score, own audits), not merged into WebPageTest’s native metrics. Other advanced features: scripting/ multi-step flows (document credentials/state/quotas), third-party domain blocking, a no-code before/after comparison feature introduced around 2022 (its current name/ availability wasn’t independently re-confirmed this pass), an API, and self-hosting.
• SEO uses: test as GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., audit redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency., check caching/CDN/TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., diagnose JS renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., and produce before/after evidence for stakeholders.
• Odd footnote: Meenan now works at Google, yet Google’s own official CWV tools page (web.dev/articles/vitals-tools) doesn’t list WebPageTest. That’s a curation gap for a third-party tool, not a signal it’s deprecated.
• Limitations: dense UI/learning curve, account needed for saved/private tests, it diagnoses rather than remediates, and single runs can mislead.

Official documentation

Primary-source documentation (Google’s mentions of WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., WebPageTest’s own docs, and a note on Bing).

WebPageTest / Catchpoint

• WebPageTest — About — the Meenan/Catchpoint origin story, the mission statement, and the Polyform Shield license.
• WebPageTest — the free public test service, including the test form, the results/filmstrip UI, and the API for programmatic testing.

Google (where it references WebPageTest — and where it notably doesn’t)

• web.dev — How To Think About Speed Tools — situates WebPageTest as the advanced lab-diagnostic option and notes you can run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. inside it.
• web.dev — Audit performance — WebPageTest for cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency./TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good./CDN checks.
• web.dev — Core Web Vitals tools — Google’s own CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. tools round-up, which does not mention WebPageTest (the curation-gap footnote).
• Google Search Central — Core Web Vitals — links out to web.dev for tool recommendations rather than naming a third-party lab tool.

Bing / Microsoft

• No Bing/Microsoft documentation references WebPageTest as a ranking input or first-party recommendation. Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility.’ own Site Scan is the nearest first-party analog. See Bing Webmaster guidelines for general guidance.

Quotes from the source

On-the-record statements about WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input.. Where a link includes a #:~:text= anchor, it jumps to the quoted passage on the source page.

Google / web.dev — where WebPageTest fits

• “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” — web.dev, “How To Think About Speed Tools.” Jump to quote
• “WebPagetest will also check static-content cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., time to first byteTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., and if your site makes effective use of CDNs.” — web.dev, “Audit performance.” Jump to quote

WebPageTest / Catchpoint — history, mission, license

• “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” — webpagetest.org/about. Source
• “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” — webpagetest.org/about. Source
• “The WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects.” — Catchpoint, webpagetest.org/about. Source

Patrick Stox (me) / Ahrefs — the CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. filmstrip technique

• “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” — from my Ahrefs Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. guide. Source
• “The exception is WebPageTest, although you can also run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. tests with it as well.” — me, on how WebPageTest differs from LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.-based tools. Source

MobileMoxie — the technical-SEO angle

• “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., caching concerns, security information, and more.” — MobileMoxie, on WebPageTest for technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own.. Source

WebPageTest cheat sheet

Where it fits vs. the other tools

The views

CLS-hunting recipe (mine)

• Filmstrip View → Highlight Layout Shifts on → Thumbnail Size: Huge → Thumbnail Interval: 0.1 secs. Watch for the frame where the layout jumps (often a web-font swap or a late image/ad).

Fast facts

• Lab, not field — does not feed Google’s CWV ranking signal (that’s CrUX).
• Read the median, never a single run — performance varies run to run.
• You can run Lighthouse inside WebPageTest — it’s not an either/or.
• Open source under the Polyform Shield license; self-hosting is possible.
• Meenan (creator) now works at Google, yet web.dev/articles/vitals-tools doesn’t list WebPageTest — a curation gap, not a deprecation.

A WebPageTest run — checklist

Get a trustworthy, useful result instead of a misleading one:

• Test location set near your real audience (distance changes the numbers).
• Device + connection profile match your users (e.g. emulated mobile on a throttled network), not your office fiber.
• Multiple repeat runs enabled — and you’re reading the median, not a single run.
• Checked the waterfall for render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. and stray redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. hops.
• Checked the connection view for a slow TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. or too many separate connections.
• Ran the filmstrip to see when main content paints — and, for CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., enabled Highlight Layout Shifts at 0.1s intervals, Huge thumbnails.
• Confirmed you’re treating the result as lab data — cross-checked the real ranking signal against CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.).
• For a suspect third party, used domain/request blocking to measure its true cost.
• For login/checkout flows, used scripting rather than testing a cold homepage.
• Saved a before/after filmstrip if you’re proposing a fix to stakeholders.

Tools that pair with WebPageTest

• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. itself (webpagetest.org) — the free public lab tool, plus the API and a paid Pro tier for volume/private tests.
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — the fast way to check the field (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) data WebPageTest can’t generate, so you know whether the ranking signal actually moved.
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — find failing page groups at scale across the site, then take a representative URL into WebPageTest to diagnose.
• Chrome DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — the local, login-friendly companion for lab profiling when you don’t need distributed locations.
• Google LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — runnable from inside WebPageTest, or standalone in DevTools/CLI for the 0–100 audit.
• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. Vis (cruxvis.withgoogle.com) — visualize the real-user field trend over time to confirm a WebPageTest-diagnosed fix landed for actual users. (See the Chrome UX Report (CrUX).)

WebPageTest mistakes that create false confidence

Treating a lab run as Google’s field verdict

WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. is synthetic data from the device, location, browser, and network profile you selected. Use it to diagnose causes; use CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. or first-party RUM to describe real users and Google’s CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. assessment.

Comparing runs with different test settings

A changed location, connection, browser, cache state, or number of runs can outweigh the code change being tested. Save the configuration and compare like with like.

Optimizing the headline score instead of the waterfall

The value of WebPageTest is request sequencing, connection setup, filmstrips, and metric timing. Trace the slow metric to a concrete request or main-thread event rather than tuning a grade in isolation.

Judging a change from one run

Lab tests vary. Run multiple tests under the same profile and compare representative results; investigate outliers instead of selecting the fastest run.

Testing only the homepage

Different templates have different LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. elements, scripts, third parties, and cache behavior. Include the pages where users and field dataPerformance metrics captured from real users, not lab tests. show the actual problem.

Prove a performance change in WebPageTest

Controlled before/after test

Test to run: save one location/browser/network/cache configuration and run multiple tests for the unchanged and changed versions. Expected result: the targeted metric and its waterfall cause improve across representative runs. Failure interpretation: the change is ineffective or test variance exceeds the effect. Monitoring window: immediate lab result. Rollback trigger: a consistent regression in the target or an adjacent Core Web Vital.

Request-sequencing test

Test to run: compare waterfalls after changing preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch., priority, blocking CSS/JS, or cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency.. Expected result: the intended request starts earlier, transfers fewer bytes, or avoids the network in the expected cache state. Failure interpretation: the hint/configuration did not apply or another dependency controls the sequence. Monitoring window: immediate. Rollback trigger: the change delays a more critical request or creates errors.

Visual-correctness test

Test to run: inspect filmstrip/video and layout-shift highlighting for the same before/after profile. Expected result: faster renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. does not introduce missing content, flashes, or new shifts. Failure interpretation: the numeric improvement traded away visual correctness. Monitoring window: every representative viewport before release. Rollback trigger: broken content or a new visible instability.

Resources worth your time

My related writing

• Core Web Vitals: A Complete Guide (Ahrefs) — includes my WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. Filmstrip recipe for diagnosing Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., the WebPageTest-vs-LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. framing, and the metrics WebPageTest measures alongside how the ranking side works. (This page absorbed my earlier “Advanced Guide to PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.” post, which now redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. here.)
• The Beginner’s Guide to Technical SEO (Ahrefs) — where web performance sits in the bigger picture.

My speaking

• Page Experience Update — TMC, June 2021 (SlideShare) — covers the same WebPageTest Filmstrip/CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. technique in talk form.
• A Crash Course in Technical SEO — Beer & SEO Meetup, May 2019 (SlideShare) — WebPageTest as part of the technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own. toolkit, back in 2019.

From around the industry

• WebPageTest — About — the primary source for the history, mission, and Polyform Shield license.
• How To Think About Speed Tools (web.dev) — Google’s own positioning of WebPageTest among the lab-testing tools.
• Audit performance (web.dev) — WebPageTest for cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., and CDN checks.
• How to Set Up WebPageTest to Evaluate Technical SEO (MobileMoxie) — the closest existing SEO-angle setup guide (GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. UA, redirects, caching, asset errors).
• A Complete Guide to Using WebPageTest (Kinsta) — the most comprehensive general explainer (history, setup, interpreting results, pricing).
• WebPageTest: A Guide To Web Performance Testing (DebugBear) — vendor-authored, but a good breakdown of multi-run averaging, waterfall/filmstrip/connection views, and scripting.

Test yourself: WebPageTest

Five quick questions on what WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. is, how to read it, and where it fits. Pick an answer for each, then check.

WebPageTest

WebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input.

Related: Core Web Vitals, Lighthouse

WebPageTest

WebPageTest is a free, open-source lab (synthetic) performance testing tool for web pages. Patrick Meenan created and open-sourced it in 2008 (it started as an internal AOL testing tool); Catchpoint acquired it in 2020, and it runs today as a free public service at webpagetest.org alongside a commercial Catchpoint product.

You give it a URL, a physical test location, a browser, and a network profile, and it loads the page on a real (or emulated) device — then hands back diagnostics that go far deeper than a single score: a waterfall chart (request-by-request, with render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. flags), a filmstrip/video view (frame-by-frame visual load), a connection view (DNS/TCP/TLS/TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. per connection), and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) you can inspect frame by frame.

The key distinction: WebPageTest data is lab data, not field dataPerformance metrics captured from real users, not lab tests.. It does not feed Google’s Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. ranking signal — that signal comes from real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data (what you see in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.). WebPageTest is what you reach for when PageSpeed Insights or LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. tells you that a page is slow but not precisely why or where in the load sequence. And “WebPageTest vs. Lighthouse” is a false choice: you can run a Lighthouse audit from inside WebPageTest.

Related: Core Web Vitals, Lighthouse

Changelog