Because the report is not measuring your code. It is measuring visits. Core Web Vitals in Google Search Console come from a rolling 28-day window of real Chrome visits, so the number moves when the visitors move, with or without a deploy.
What is actually being scored here?
Three metrics, each judged at the 75th percentile of real visits rather than at the average. Google's published thresholds are 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, and 0.1 for Cumulative Layout Shift.
The 75th percentile is the part people skip, and it explains most mystery movement. A page passes only when three visitors in four get a good experience. The worst quarter of your traffic sets your score, so anything that changes the composition of that worst quarter changes the grade. The code is one input. Devices, networks, geography and cache state are the others, and none of them are in your repository.
Why does a rolling window move on its own?
Each day the window gains a day and drops the one from 29 days ago. A single bad week stays in the number for four weeks, then leaves on its own, which produces a cliff on a day when nothing shipped.
This cuts both ways. A fix you shipped three weeks ago is still being averaged against the three weeks of badness that preceded it, which is why a real improvement looks like it did nothing. The same mechanism also means a sale week, a newsletter send or a press mention can sit inside your window long after the traffic spike ended.
A field score is a property of your visitors as much as your code. Before you open the templates, find out whether the page changed or the audience did.
Which changes are yours and which belong to your traffic?
| What you see | Usually means | First check |
|---|---|---|
| One metric degrades, no release in the window | Traffic mix shift, or a third-party script updated itself | Device and country split in the field data |
| All three degrade on the same day | A platform, theme or CDN change you did not make | Host, theme and plugin update logs |
| Score worsens while lab tests stay fast | Real conditions you cannot reproduce on a desk | Mobile share and connection types |
| A page group appears or disappears | Search Console regrouped similar URLs | Which URLs are in the group now |
| Field data vanishes entirely | Not enough visits to report | Traffic volume on that URL pattern |
Does mobile traffic growth really change the grade?
Yes, and it is the most common innocent explanation. Mobile and desktop are reported separately, but the mix inside each segment still shifts, and a phone on a slow network is the visit that defines your 75th percentile.
Pick up more organic search traffic from a country with slower average connections and your score drops while your code is byte-identical. Run a campaign that brings cold, uncached first visits and the same thing happens, because a first visit pays for every font, script and image your repeat visitors already have. Growth can look like a regression.
What about third-party scripts you never touched?
Tag managers, consent banners, chat widgets and ad scripts update themselves on the vendor's schedule, not yours. Your deploy log is clean and the page still got heavier.
These are the hardest regressions to attribute because nothing in version control changed. The practical test is to load the page with third-party requests blocked and compare. If the blocked version is dramatically better, the regression is in code you ship but do not write, and the fix is a conversation about tags rather than a refactor.
Reacting to a one-day movement. The window needs weeks to settle, so a single day's change is rarely signal. Wait for a trend, or confirm the regression in lab testing you can run on demand.
How do you confirm a regression you can actually fix?
Reproduce it in lab conditions. Lab tools respond immediately and deterministically, so if a throttled test on a mid-range phone profile shows the same problem, you have something to debug today instead of a number to watch.
If lab tests stay fast while the field number stays bad, the gap is your real audience: slower devices, worse networks, or a page state you never test, like a logged-in header or a cookie banner on first paint. That gap is still your problem, but the fix lives in what you serve those visitors, not in your local build. The crawler view is no help here either, since bots are not represented in field data at all.
What is worth watching, and what is worth ignoring?
Watch the direction over four weeks and the percentile that fails. Ignore daily wobble, small group reshuffles, and the urge to chase a number that moved because you got more visitors.
The Web Vitals that matter are the ones that keep failing after a full window has turned over with your current code in place. Anything that resolves itself inside 28 days was the window, not the site.
So which is it on your site this week?
You have two questions to answer before anyone writes a ticket: did a release land inside the current window, and did the device or country mix move. If the answer to both is no, something you ship but do not author changed, and that is where to look first.