Definition
When you measure web performance, several numbers come out, and the topic of this article is "telling apart what value each number actually represents." If you mistake different measurements for the same thing, you end up optimizing the wrong place.
Three things to distinguish:
- Lighthouse Performance score (0–100): an aggregate score that Google's performance measurement tool Lighthouse assigns by combining several metrics into one.
- Category audits (A11y/SEO/BP): the accessibility (A11y), search optimization (SEO), and Best Practices (BP) scores that the same Lighthouse assigns. These are separate from performance.
- LCP·CLS from a Chrome Performance trace: the raw measurements you get when you record (trace) a page once with the browser's DevTools. It shows LCP (Largest Contentful Paint — the time until the largest content is painted on screen, in ms) and CLS (Cumulative Layout Shift — how much the screen shifted, dimensionless) as actual milliseconds and figures.
These three differ in both tool and aggregation method, so they do not map 1:1.
Why it's needed
Problem situation: if you lump together "SEO 100 in the audit" and "LCP 900ms in the trace" and read them as "good performance," your optimization priorities get skewed. A high SEO score can coexist with actually slow loading.
They differ in principle. The Performance score is a lab (lab — measurement reproduced in a controlled environment on a single machine) score that synthesizes several metrics with weights, such as LCP·CLS·TBT (Total Blocking Time — the total time the main thread was blocked and unable to respond to input)·FCP (First Contentful Paint — the moment the first content was painted)·SI (Speed Index — how fast the screen filled up). The ms value from a trace, by contrast, is a single value observed on that one navigation.
Moreover, if you don't fix the environment (dev build vs. real production build, whether you throttle the network artificially, whether it's a cache-less first run, i.e. cold start), the same code can yield opposite conclusions. So you must always look at "what number measures" plus "in what environment the number was measured" together.
How it works
| Instrumentation | Unit | Meaning |
|---|---|---|
| Trace LCP/CLS/TTFB | ms / dimensionless | The lab CWV of this reload |
| Lighthouse Performance | 0–100 | Weighted average after log-normal mapping of several metrics |
| Lighthouse A11y/SEO/BP | 0–100 | Pass rate of that category's audit rules |
Even if you reduce LCP ms, a bad TBT can cap the Performance score. Conversely, even at SEO 100, LCP ms must be looked at separately.
Comparison rules:
- Fix the same URL · same auth · same build · same throttle.
- No single trace — take the median over N runs, like lab-performance-measurement-variance.
- Never compare absolute values of dev median vs. production median — only before/after within each environment.
Practical application
- During development: Chrome Performance trace reload → LCP/CLS/TTFB ms, median of 3.
- Category regression: Lighthouse A11y/SEO/BP audit.
- Release gate: the same protocol after
build && start. - Don't record an outlier run in the headline.
Trade-offs
| Choice | Benefit | Cost |
|---|---|---|
| trace ms centered | Sensitive to implementation iteration | May not match the intuition of the Lighthouse score |
| Lighthouse Performance only | A single number | Hard to decompose the cause of LCP ms |
| RUM (field) | Real-user distribution | Separate from lab reproduction·debugging |
When not to use
- Claiming an LCP SLA is met based on the SEO audit score alone.
- Saying a single dev cold run represents production performance.
Common mistakes
- "Lighthouse 100 = best LCP" (the category might not even include Performance).
- Not checking TBT/CLS to explain why the Performance score didn't rise even though you only improved LCP ms.
- Listing traces of different build·auth states on one timeline and asserting regression/improvement.
Related concepts
- lab-performance-measurement-variance — median of N runs·outliers
- largest-contentful-paint — LCP composition·improvement
- critical-rendering-path — TTFB·render pipeline