What Is PageSpeed and How Do You Measure It?
PageSpeed is the general term for how quickly a web page loads and becomes usable — it is a concept, not a single number. You measure it with tools that capture different things: lab tools like Lighthouse and PageSpeed Insights give you a repeatable score and diagnostics, while field data (Core Web Vitals from real visitors) tells you what users actually experienced. If you want to know whether a page is fast, you need both, plus a way to see the load unfold over time rather than as one average.
PageSpeed vs. PageSpeed Insights vs. Lighthouse
These three get used interchangeably, but they are not the same thing.
| Term | What it is | What it gives you |
|---|---|---|
| PageSpeed | The general concept of page load speed | No tool, no score — a quality of the page |
| PageSpeed Insights | Google's web tool that runs a page and reports results | Lab score plus field Core Web Vitals data when available |
| Lighthouse | The open-source audit engine behind many speed tools | A performance score, metric timings, and a list of opportunities |
So "our PageSpeed is 62" is shorthand for "a Lighthouse-based audit scored this page 62." That number is a lab estimate under simulated conditions, not a measurement of your real visitors.
The metrics that actually describe PageSpeed
A single load time hides the fact that a page loads in stages. These are the milestones worth tracking:
- TTFB (Time to First Byte) — how long the server takes to start responding. A slow TTFB caps everything downstream.
- First Contentful Paint (FCP) — when the first text or image appears.
- Largest Contentful Paint (LCP) — when the main content block is rendered. This is the Core Web Vital most tied to perceived speed.
- Total Blocking Time (TBT) — how long the main thread is busy and the page can't respond to input.
- Cumulative Layout Shift (CLS) — how much visible content moves around while loading.
- Interaction to Next Paint (INP) — how responsive the page feels once you start clicking and typing.
LCP, CLS, and INP are the three Core Web Vitals. Lab tools estimate them; field data measures them from real sessions.
How to measure PageSpeed
1. Start with a lab audit
Run the page through Lighthouse (in Chrome DevTools under the Lighthouse panel) or PageSpeed Insights. You get a performance score, the metric timings above, and a prioritized list of things to fix — oversized images, render-blocking scripts, unused CSS, and so on. Run it more than once; scores vary between runs.
2. Check field data
PageSpeed Insights shows real-user Core Web Vitals when the page has enough traffic, drawn from the Chrome UX Report. This is the number that reflects actual experience, including slow devices and networks your lab test doesn't simulate. If field and lab disagree, trust the field data for "is it fast for users" and the lab data for "why."
3. Watch the load frame by frame
Scores and single timings flatten the experience. A filmstrip view — a sequence of screenshots captured at intervals during load — shows what a visitor actually sees: when content appears, when it jumps, when it's finally stable. Tools built around this idea, such as Lightest, put pages on a shared timeline so you can compare how two sites load side by side, frame by frame. That comparison is useful when you want to see where the gap is, not just that one page scores lower.
4. Verify the fix
After changing something, re-run the same lab audit under the same conditions and compare the specific metric you targeted. If you optimized images for LCP, check LCP — not just the overall score, which can move for unrelated reasons.
Common causes of slow pages
- Unoptimized images — large files, wrong formats, no responsive sizing. Usually the biggest single LCP contributor.
- Render-blocking resources — CSS and synchronous scripts in the head that delay first paint.
- Too much JavaScript — large bundles and heavy third-party scripts raise TBT and hurt INP.
- Slow server response — high TTFB from poor hosting, no caching, or slow backend queries.
- Layout instability — images and ads without reserved dimensions cause CLS.
Where to start
Fix in order of impact: server response first (it gates everything), then the largest image or content block (LCP), then JavaScript weight (TBT/INP), then layout stability (CLS). Measure before and after each change with the same tool so you can attribute the improvement. Use lab tools to diagnose, field data to confirm it mattered, and a frame-by-frame comparison when you need to see the load as a visitor experiences it.