A page's performance is not a value you set on launch day. It is a value that changes for six months afterwards. A third party adds a tag, another font loads, a component library gets upgraded, an image is re-exported. None of these is a bug. Together they can produce a regression that none of them caused on its own.
And you usually do not notice. The page loads, it does not error, conversion does not visibly change. It just gets slower.
Three metrics, three different questions
LCP (Largest Contentful Paint) — when did the largest element appear? This is the user's "the page loaded" feeling.
When it degrades, the usual suspects: an unoptimised hero image, a font loading early in the critical path, another JavaScript bundle added for no clear reason.
CLS (Cumulative Layout Shift) — how much did the page move while loading? This is the main reason users click the wrong thing.
When it degrades, the usual suspects: an image with no dimensions, an ad that loads late, a banner injected after the fact.
INP (Interaction to Next Paint) — after a user clicks, how long until the interface responds?
When it degrades, the usual suspects: main-thread work, event handlers, heavy libraries.
Why continuous measurement, not a one-off score
The standard approach: paste your URL into PageSpeed Insights, get a score. One measurement, three problems.
1. One moment, one measurement. Real users arrive on different devices, networks and times of day. A lab score is one scenario and does not show the real distribution.
2. You miss the moment of the regression. The metric got worse because of a button. Nobody was looking then. By the time anyone notices, you do not know which change caused it.
3. Looking at your server is not enough. These metrics are measured on the user's device. Your server can be perfectly healthy while the metric degrades.
Continuous measurement solves the second one: you see whether the metric actually moved after each change.
How to catch a regression
1. Attach the measurement to the change
A page changed, LCP got worse. If you cannot connect those two, you will always say "probably that change" instead of knowing it.
What works in practice: every change record carries the page's metric value at that moment. Two weeks later you can look back and see which change moved the metric and by how much.
For that, your change history has to carry why, not just "something changed". That is what an evidence archive is for.
2. Track per page, not per site
A site average is misleading. If your homepage got faster and your product pages got slower, the average may not move at all.
Track per page. The page that regressed is usually a single page, and that is also where the revenue is.
3. Set thresholds from real data
If a page's LCP is 2.4s and your threshold is 2.5, every change leaves it just under the line. The next small change crosses it and an alert fires — but nothing actually changed.
This is a textbook case of alert fatigue: if the threshold stays at "something changed", your system is watching pixels, not regressions.
What makes pages slow, in order
Metrics tell you that something degraded. They do not hand you a to-do list — and that is deliberate. A metric is a diagnosis, not a treatment.
The four causes you will meet most, in roughly this order:
Images. The most common. No dimensions, no modern formats, larger than necessary. On their own, the most frequent cause of LCP.
JavaScript bundles. Every library added occupies the main thread. They degrade INP and, indirectly, LCP.
Fonts. Every family and weight is a separate file. Without display=swap, text
is invisible until the font arrives.
Third-party scripts. Ads and tag managers. The only thing outside your control that directly affects performance, and the one most often added late.
Where to start
Four steps, in this order:
- Pick three page types. Home, listing, product. Where the money is. Not all of them.
- Measure for a week without changing anything. This is how you learn what your real numbers are.
- Set thresholds from what you saw, per page. They may differ per page.
- Only then connect change tracking. Now "the metric got worse" can be answered with "because of this change".
This is the web-vitals equivalent of the questions in what to check when choosing a tool: which metrics it measures, how much history it keeps, whether the threshold is configurable.
Summary
- Web vitals degrade continuously, and quietly, because the page keeps working.
- A one-off score misses the moment of the regression; continuous measurement catches it.
- Track per page. A site average hides the page that broke.
- Metrics diagnose, they do not treat. The four usual causes: images, JavaScript, fonts, third-party scripts.
- The first week is for measuring, not changing.
The same logic applied to how a page looks is covered in what visual regression testing is.