A site clears a Core Web Vitals audit, and three months later the same warning is back — same pages, same metric, sometimes the same score it started at. Nothing was redesigned in between. No major launch, no obvious regression anyone would have flagged. The audit failed anyway.
That pattern is more informative than the audit itself. A single pass or fail on a Core Web Vitals audit tells you how a site performed on one specific day, under one specific set of conditions. It says nothing about whether those conditions will hold. Treating an audit result as a fixed outcome — something checked off and left alone — is usually why the same finding resurfaces.
What Core Web Vitals Actually Measure
Core Web Vitals measure three things: how quickly a page’s main content becomes visible, how quickly it responds to interaction, and how much its layout shifts while loading. Together they describe loading performance, interactivity, and visual stability — three separate scores read as one health indicator. A page that loads fast but shifts around while doing it will still fail, even though speed looks fine on paper.
None of that changes once a site launches.
What changes is everything downstream of launch. A fuller explanation of how the three metrics interact lives on the site’s core web vitals explained page; this is about what happens to that score after the explanation stops mattering and the site goes live.
Three Places Optimization Gets Undone Between Audits
The erosion tends to happen in the same few places:
- A new marketing or analytics script gets added after launch, outside whatever performance budget the original build was held to.
- CMS image uploads bypass the compression and sizing rules enforced during development, because nothing enforces them afterward.
- A third-party embed — a chat widget, a video player, a review plugin — gets added later and brings its own loading cost with it.
None of these require a mistake. They require only that no one is watching the budget after the people who set it move on to the next project.
Why a Core Web Vitals Audit Passes Once and Fails the Next Time
An audit captures a site as it exists on the day it runs. Every change made after that day is invisible to the audit until the next one runs.
Marketing adds a new tracking script. The CMS accepts an oversized image because no one enforced the compression rule at upload. A vendor updates a third-party widget, and the update ships a heavier script than the version that was tested. None of these are performance decisions.
Each one still costs performance, regardless of who made the change or why.
This is the gap an audit can’t see by design. It’s a point-in-time measurement of a system that keeps moving after the measurement is taken.
Why the Fix Has to Be Structural, Not Just Another Audit
Running the audit again doesn’t fix any of this.
It just measures the damage after it’s already been done, producing the same finding, the same recommendation, and the same short-lived fix as last time.
A website performance system treats performance as a constraint maintained on an ongoing basis, not a milestone hit once. That means someone owns the budget after launch — reviewing what gets added to the site, catching the script or the image or the embed before it ships. Otherwise it turns up three months later, in an audit that reads like the last one.
An audit that keeps finding the same problem isn’t telling you the fix failed — it’s telling you the fix was never structural to begin with.