You shipped a change that clearly cut LCP, but a week later the Core Web Vitals field data for that page has barely moved. Why, and what would you look at in the meantime?

## The window is the whole answer Field Core Web Vitals are published as an aggregate over a **rolling 28-day window** of real visits. Each day the window slides forward: the oldest day of samples drops out, a new day drops in. The published value is a percentile computed over everything currently inside that window. That single fact explains the symptom. Seven days after your deploy, the window holds roughly 21 days of pre-fix visits and 7 days of post-fix visits. Even if every new visit is dramatically faster, they are a minority of the pool, and a percentile over a pool that is three-quarters old data mostly reflects old data. You get a slow drift, not a step change, and the full effect lands only after the window has turned over. A useful mental model: the reported value is a moving average of your last month of reality. Ship something great and the line bends gently; ship something terrible and, reassuringly or alarmingly, the line also bends gently. ## Second-order lags stacked on top Several effects extend the wait beyond the window arithmetic: - **Reporting lag.** Dashboards built on the dataset do not always show today's window; they publish on their own cadence, so what you see can already be days behind the underlying aggregate. - **Traffic seasonality.** If your traffic is weekly-cyclical, the composition of the window changes with the day of the week, adding wobble that can mask a modest improvement. - **Returning visitors and caches.** Users who already have your old assets cached may not experience the new path immediately, depending on what you changed and how it is cached. - **Partial rollout.** If the change went out behind a flag or to a fraction of traffic, the post-fix share of the window is smaller than the calendar suggests. ## What to do instead of waiting The cure is your own real-user measurement with a **release or deploy identifier attached to every sample**. Then the comparison is not "before vs after in a smeared window" but "visits tagged build A vs visits tagged build B", which you can read within hours of the deploy at meaningful volume. Compare distributions, not means: look at the same percentile the public assessment uses, plus the shape, because a fix that improves the median while leaving the slow tail untouched will not move the assessment at all. Segment that comparison the same way the assessment does — by form factor at minimum, and ideally by connection quality and geography. This is where you catch the most common disappointment: the change genuinely helped fast devices, where you tested, and did nothing for the slow quarter, which is the only quarter the percentile rule cares about. ## Don't over-interpret early movement The flip side of the lag is that early wiggles in the public number are mostly noise: a couple of days of new data cannot move a 28-day percentile much, so any large jump you see in that period is more likely a change in traffic mix, a sampling artefact, or a reporting-surface update than the effect of your work. Resist the urge to declare victory or defeat from three days of drift. ## Answering it well The strong answer has three parts: state the window and do the arithmetic out loud (a week in, most samples are still old); name the second-order lags without treating them as the main cause; and pivot immediately to the thing you control — release-tagged real-user data, compared at the same percentile and segmented by form factor. That last part is what separates an engineer who understands the reporting from one who merely waits on it.