WebPageTest vs PageSpeed Insights: complete comparison

Candidate 1 — duo lab/field

WebPageTest

Lab data

Paris · Moto G4 · 4G Waterfall

HTML

CSS

JS

IMG (LCP)

API

tracker

Filmstrip 100ms / frame

LCP Good

1.2s

1 test from Paris · Moto G4 · 4G, deterministic

PageSpeed Insights

Lab + Field

Field · CrUX

D-28

today

P75

CrUX P75

2.4s Needs improvement

Lab · Lighthouse

0

Perf

0

A11y

0

BP

0

SEO

0

Lab score (Lighthouse) + field data (CrUX, 28d), in one report

Candidate 2 — two loupes

example.com

WPT · lab

DNS · 80ms

req#3 · blocking

filmstrip · 100ms/f

→ LCP 1.2s

PSI · lab + field

Lighthouse · lab score 78

CrUX P75 · real users

window · 28d

→ 2.4s field + 78 lab

Same URL, two diagnostic lenses

Why picking the right tool changes everything

A performance audit run with the wrong tool produces two textbook symptoms: a Lighthouse score of 95 in PageSpeed Insights while real users see a 4-second LCP on mobile, or — the other way round — a site that passes its Core Web Vitals in the field but stays opaque the moment you try to understand why a regression just landed. The cause is almost always the same: lab data and field data got mixed up, or a synthetic number was treated as user-experience truth.

That's the WebPageTest vs PageSpeed Insights debate — and it isn't won by picking a side. The two tools are complementary, as long as you know which one answers which question.

The fundamental difference: lab data vs field data

Mobile vs Desktop

Core Web Vitals by device type

Mobile

LCP 3.8s

INP 280ms

CLS 0.18

Desktop

LCP 1.6s

INP 90ms

CLS 0.04

60% of your visitors are on mobile – mobile optimization is a priority

This is the axis everything else hangs on. Methodology, metrics, use cases — they all follow from this one distinction.

Lab data: the page is loaded in a controlled browser with a fixed network and CPU profile (e.g. Slow 4G, 4× CPU throttling). One run gives you a reproducible number. That's what WebPageTest and Lighthouse produce. Upside: deterministic, ideal for before/after comparisons or catching a regression on a commit. Downside: a single synthetic scenario that doesn't reflect the diversity of real devices and connections.

Field data: metrics collected from actual Chrome user loads (CrUX, Chrome User Experience Report), aggregated over a rolling 28-day window and reported at the 75th percentile. That's what PageSpeed Insights shows in its "Real-world data" block — and that's what Google uses as a Page Experience signal. Upside: it's reality. Downside: 28-day lag, and no way to drill down into a specific session.

An important nuance to keep in mind: both tools surface CrUX data for the URL under test when Chrome has enough traffic on it. Kicking off a WPT run at time T pulls up the CrUX block just like PSI does, since both hit Google's CrUX API. The comparison isn't really "lab vs field" as it's often simplified to ; it's "very deep lab + field" (WPT) vs "fast lab + field, one-click access" (PSI).

Practical takeaway: PSI tells you whether there's a problem, WPT tells you why. A performance fix is only definitively validated in field data — but it's built in lab data.

WebPageTest: what it does best

Network waterfall

Before 4,490ms

index.html

320ms

styles.css

280ms

app.js

850ms

vendor.js

1200ms

fonts.ttf

520ms

hero.png

980ms

jQuery.js

340ms

After optimization 590ms

index.html

120ms

styles.css

70ms

app.js

180ms

vendor.js

Removed

fonts.woff2

80ms

hero.avif

140ms

jQuery.js

Removed

Total gain: -87% 3,900ms saved

Html Css Js Font Image

WebPageTest (WPT), now owned by Catchpoint, is first and foremost a lab data tool — with the deepest diagnostic toolset on the market — and its report also surfaces the CrUX block for the URL under test when Chrome has the data, exactly like PSI. It's the gold standard for synthetic testing, across several layers.

On the infrastructure side, the free Starter plan gives access to 30 locations worldwide — including mainland China — on real physical devices (Moto G4, iPhone, Chrome desktop profiles). The Pro plan unlocks 35 locations total, with queue priority and premium locations. That's how you discover that a site loading in 1.2 s from Paris can show 4.8 s from Mumbai on the very same Moto G4 — a gap that's invisible to any single-location tool. For a site serving multiple geographies, it's non-negotiable.

On the visual diagnosis side, the waterfall breaks down each request into DNS, connect, TLS, TTFB and download: you immediately see the request blocking your LCP, the preload that wasn't honored, the third-party script delaying another critical asset. The filmstrip records the visual state of the page every 100 ms (configurable up to 60 fps) and produces a video: you pinpoint exactly when the hero appears, when a layout shift fires, at which frame the "Add to cart" button becomes clickable. PSI only provides an end-of-load screenshot.

Beyond Core Web Vitals, WPT exposes the Speed Index (introduced by Pat Meenan in 2012, a weighted visual completeness metric), TTFB, Start Render, Total Blocking Time, and your own User Timings — any mark created via performance.mark() shows up in the report automatically. You can also inject custom JavaScript to measure whatever has no standard metric (time until the cart becomes interactive, DOM size at a given moment, presence of a specific element). To filter network noise, multi-run testing (3 by default, configurable) with median is the norm — and several URLs can be compared side by side with synchronized filmstrips, handy for benchmarking against a competitor.

The two features that put WPT in a category of its own are scripting and the API. Scripting lets you audit a page behind a login, or a PDP reached after multiple clicks from the home page — you navigate, fill a form, click, wait, and only record metrics on the target page:

logData 0
setCookie https://example.com session=abc123
navigate https://example.com/login
setValue id=email user@example.com
setValue id=password ***
clickAndWait id=submit
logData 1
navigate https://example.com/dashboard

logData 0 disables recording during setup, logData 1 re-enables it on the page you actually want to measure. Flatly impossible in PSI. The REST API (Pro plan) lets you automate all of this: tests in a CI pipeline, feeding an internal dashboard, triggering on every deploy. It's also what lets WPT integrate with platforms like SpeedCurve or Calibre.

PageSpeed Insights: what it does best

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

PageSpeed Insights (PSI), owned by Google, has a unique feature: it's the only mainstream tool that combines lab data (a Lighthouse run) and field data (the CrUX block) in the same report. Its two assets sit in that duality — one-click access, no install.

On the field side, the "Real-world data" block at the top of the report shows LCP, INP and CLS measured on real Chrome visits to your URL (or to your origin if the page lacks enough traffic), at the 75th percentile over 28 days. It's the very same data Google uses for the Page Experience signal — no lab audit can produce it.

On the lab side, PSI runs Lighthouse 13 in a Google-controlled environment with a fixed mobile profile (emulated Moto G4, Slow 4G, 4× CPU throttling) and returns a 0–100 score per category (Performance, Accessibility, Best Practices, SEO) along with a list of actionable audits — each audit paired with an estimated gain (ms saved, KB saved) and a root-cause explanation. It's exactly what lighthouse https://example.com produces locally, but with nothing to install.

Access is universal: URL, "Analyze" button, 30 seconds, no account, no technical skill required. It's the tool you share with a product manager or a client. The v5 API (free Google key) extends that accessibility to monitoring: 25,000 requests per day and 400 per 100 seconds — plenty to audit a catalog of several hundred URLs daily, something out of reach on the WPT free plan. And since the API returns both (Lighthouse + CrUX), one call is enough to track lab and field in parallel.

Side-by-side comparison

Use cases: which tool for which job

Once the matrix is laid out, the verdict comes by scenario, not by tool.

Limits and pitfalls to know about

No single tool tells the whole truth. Four pitfalls show up over and over.

The Lighthouse score is not a direct SEO signal. A 95 in PSI has no influence on ranking — what matters to Google is the CrUX block in the same report, i.e. P75 field data. Optimizing to push the score up without touching the field data is decorative work.

A single WPT run is worthless. The network is noisy, a shared agent's CPU fluctuates; always run at least 3 runs and take the median. On 100–200 ms optimizations, a single run can produce a false positive (or false negative) that costs you a day of work.

The PSI score moves on its own. Three PSI runs 30 seconds apart on the same URL can return 85, 92, 78 without you touching the site — the variance comes from the Google datacenter serving the test, the embedded Lighthouse version (sometimes one or two cycles behind the public Lighthouse CLI), and the shared environment. The takeaway: an isolated score never validates an optimization on its own, and the actionable recommendations need filtering — PSI regularly suggests removing Google Ads, Analytics scripts or YouTube embeds that are actually critical to revenue.

And finally, CrUX can be empty. For a URL to have its own CrUX data, it needs a minimum Chrome traffic threshold. On a low-traffic page, PSI falls back to origin-level data (the whole site) — or shows nothing. Easy to miss if you skim.

💡 Tips for reading PSI correctly: always check that the "Real-world data" block is on the URL and not on the full origin (a toggle exists). If CrUX is empty, don't conclude performance is good or bad — absence of data is absence of data. And keep in mind that INP replaced FID in the Core Web Vitals in March 2024: if your internal dashboard still tracks FID, you're tracking a dead metric. See [Core Web Vitals: INP replaces FID](https://pauld.fr/en/advices/core-web-vitals-inp-march-2024) for the full context.

The ecosystem around WPT and PSI

Reducing performance tooling to these two tools means missing half the landscape. The neighbors to know, with their respective niches:

Practical recommendations

The right setup depends less on your preferences than on your context:

FAQ

Sources

• WebPageTest Documentation
• Catchpoint WebPageTest — pricing & plans
• PageSpeed Insights — Google for Developers
• CrUX (Chrome User Experience Report) — documentation
• web.dev — Core Web Vitals
• web-vitals library — GitHub