WebPageTest vs PageSpeed Insights: a complete comparison

Why the right tool changes everything

A performance audit built on the wrong tool produces two typical symptoms: a Lighthouse score of 95 in PageSpeed Insights while real users experience a 4s LCP on mobile, or conversely a site that passes Core Web Vitals in the field but remains opaque when you try to understand why a regression just appeared. The cause is almost always the same: lab data and field data have been confused, or a synthetic figure has been interpreted as a user experience truth.

This is the WebPageTest vs PageSpeed Insights debate — and it isn't settled by naming a winner. The two tools are complementary, as long as you know which one answers which question.

The fundamental difference: lab data vs field data

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

This is the axis that structures everything else. Everything that follows (methodology, metrics, use cases) flows from it.

Lab data: the page is loaded in a controlled browser, with fixed network and CPU settings (e.g. Slow 4G, CPU 4× throttled). One run yields a reproducible number. This is what WebPageTest and Lighthouse produce. Advantage: deterministic, ideal for before/after comparisons or detecting a regression on a commit. Limitation: a single synthetic scenario, which doesn't reflect the diversity of real devices and connections.

Field data: metrics are collected from real page loads by real Chrome users (CrUX, Chrome User Experience Report), aggregated over a rolling 28-day window and reported at the 75th percentile. This is what PageSpeed Insights displays in its "Real User Experience" section — and what Google uses as a signal for Page Experience. Advantage: it's reality. Limitation: 28 days of latency, and impossible to drill down to a specific session.

An important nuance to keep in mind: WPT produces only lab data, whereas PSI produces both — a Lighthouse run (lab) plus the CrUX block (field) in the same report. The comparison is therefore not "lab vs field" as it's often simplified; it's "pure, very deep lab" (WPT) versus "lab + field, accessible in one click" (PSI).

Practical consequence: PSI tells you whether there's a problem, WPT tells you why. An optimization is only definitively validated in field data — but it's built in lab data.

WebPageTest: where it excels

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 published by Catchpoint, is a pure lab data tool — no field data here, but the deepest diagnostic capability on the market. It's the benchmark for synthetic testing, across multiple 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 total, with queue priority and premium locations. This is what makes it possible to observe that a site loading in 1.2s from Paris can show 4.8s from Mumbai on the same Moto G4 — a gap invisible with a single-location tool. For a site serving multiple geographic regions, this is non-negotiable.

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

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

The two features that put WPT in a class of its own are scripting and the API. Scripting lets you audit a page behind a login, or a PDP reached after several clicks from the home page — you navigate, fill in 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. This is completely impossible in PSI. The REST API (Pro plan) automates all of this: tests in a CI pipeline, feeding an internal dashboard, triggering on each deploy. It's also what allows WPT to integrate with platforms like SpeedCurve or Calibre.

PageSpeed Insights: where it excels

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

PageSpeed Insights (PSI), published by Google, has one unique characteristic: it's the only mainstream tool that combines lab data (a Lighthouse run) and field data (the CrUX block) in a single report. Its two strengths lie in this duality — accessible in one click, without any installation.

On the field side, the "Real User Experience" block at the top of the report displays LCP, INP and CLS measured on real Chrome visits to your URL (or your origin if the page doesn't have enough traffic), at the 75th percentile over 28 days. This is exactly the 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 environment with a fixed mobile profile (emulated Moto G4, Slow 4G, CPU 4× throttled) and returns a 0-100 score by category (Performance, Accessibility, Best Practices, SEO) with a list of actionable audits — each audit accompanied by a gain estimate (ms saved, KB saved) and an explanation of the root cause. This is exactly what lighthouse https://example.com produces locally, but without installing anything.

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

Point-by-point comparison

Use cases: which one for what

With the matrix in place, the verdict comes by scenario, not by tool.

Limitations and pitfalls to know

No tool tells the whole truth. Three pitfalls come up repeatedly.

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. field data at P75. Optimizing to raise the score without touching 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-200ms optimizations, a single run can produce a false positive (or false negative) that wastes a full day.

Finally, CrUX can be empty. For a URL to have its own CrUX data, it needs a minimum threshold of Chrome traffic. On a low-traffic page, PSI falls back to origin data (the whole site) — or displays nothing. This is invisible if you read too quickly.

💡 Best practices for interpreting PSI: always verify that the "Real User Experience" block is showing data for the URL, not the entire origin (a toggle exists). If CrUX is empty, don't conclude that performance is good or bad — absence of data is absence of data. And keep in mind that [INP replaced FID in Core Web Vitals in March 2024](https://pauld.fr/en/advices/core-web-vitals-inp-march-2024): if your internal dashboard still tracks FID, you're tracking a dead metric.

The ecosystem around WPT and PSI

Limiting your performance tooling to these two tools means missing half the landscape. The neighbors worth knowing, with their respective niche:

Practical recommendations

The right setup depends less on your preferences than on your usage 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