The deploy goes out on a Tuesday. The lab test that morning showed a failing largest contentful paint; the same test that afternoon passes comfortably. By Friday somebody checks the Core Web Vitals report, finds the URLs still sitting in the failing group, and asks whether the fix actually worked.
It probably did. The two numbers come from different places, and only one of them can change on a Tuesday.
Why does the report not move the day after the deploy?
Because it is not measuring your site today. It is summarizing visits collected over a window of recent weeks, most of which happened before your fix existed.
A lab test loads the page once, right now, on a machine you chose. Field data records what real visitors experienced across every device, network and cache state they happened to bring. When a report is built from a rolling twenty-eight days of those visits, a fix deployed today competes with twenty-seven days of the old behavior. The average moves, but slowly, and it moves least on the first day.
A rolling window does not update — it dilutes. Every day after the fix, one day of old measurements leaves the window and one day of new ones enters. The number does not jump when the fix lands; it drifts toward the new reality over the length of the window.
How long until each report reflects reality?
It depends entirely on which tool you are reading, and they disagree by weeks.
| What you are looking at | When it reflects the fix | Why |
|---|---|---|
| Lab test in a browser dev tool | Immediately | It loads the page you just deployed |
| Your own real-user monitoring | Hours to a day | You control the window and can look at today alone |
| Public field dataset for a URL | Weeks, drifting | Rolling window of recent real visits |
| Origin-level field summary | Weeks to months | Every page on the domain is averaged in |
| Search Console vitals report | Weeks, then a status flip | Built on field data, then grouped into pass or fail bands |
The origin row explains most confusion. If you fixed one template and the summary covers the whole domain, the fix is being averaged against thousands of untouched pages and may barely register even after it has fully propagated.
Why do some pages update faster than others?
Traffic volume. A field measurement is an aggregate of real visits, so a page that gets thousands of visits a week reaches a stable new number long before one that gets forty.
Low-traffic URLs are usually reported as part of a group of similar pages rather than individually, which has two consequences worth planning around. A fix to one page in the group barely moves the group, and a fix applied to the template behind the whole group moves it decisively. The practical instruction is to fix at the template level whenever the failure is a template problem, which it usually is.
What should you watch while you wait?
The distribution, not the pass or fail label. A rolling window hides progress inside a status that stays red until it crosses a threshold, and the underlying spread shows movement much earlier.
If you record your own performance data, segment it to the days after the deploy and compare it with the days before. That comparison has no rolling window in it and gives a clean answer within about a day. If you do not record it, this is the argument for starting: a web vitals collection script is small, and it converts a month of waiting into an afternoon of checking.
Deploying a second fix while the first is still propagating. When the number finally moves you will not know which change did it, and if it moves the wrong way you have two suspects and no way to separate them.
What if nothing has changed after two months?
Then the fix did not reach real visitors, and the place to look is the gap between your test conditions and theirs. Two months is past the point where a rolling window explains anything.
The usual causes, in the order worth checking:
- Device mix. The public field data most people read is mobile-weighted, and a fix validated on a desktop machine may do nothing for a mid-range phone on a slow connection.
- Partial coverage. The template you fixed is not the template most visits land on. Check which URLs actually carry the traffic before assuming the fix was where the problem was.
- Something reintroduced it. A tag added through a tag manager after your deploy can restore the exact cost you removed, and it will not appear in your repository.
- The wrong element. The fix improved something real that was not the thing being measured — a common outcome when the failing element was never identified precisely.
A crawler-based audit of the live pages settles the second and third cases quickly, because it shows what is shipping now rather than what the repository says should be shipping.
How should this change how you schedule the work?
Batch the fixes for a template, ship them together, and set the review date at the far end of the window rather than the near end. Checking a rolling metric weekly produces noise and invites a second change before the first has been judged.
Before your next performance deploy, write down the date you will judge it on and which number you will judge it with. Doing that afterwards is how a fix that worked gets reverted.
Fixed the problem and the report still says failing?
We will check whether the fix reached real visitors or only the test harness, and tell you which number to watch while it propagates.
Get in Touch →Does this apply to your site?
Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.
Free and unlimited. No account, no card, and you get every finding rather than a teaser.