Why Your Speed Fix Won't Show Up for 28 Days
Here is a scenario that plays out in small businesses with regularity.
A developer fixes a site speed problem. They confirm it in Lighthouse within 20 minutes. They tell the owner the fix is done.
Two weeks later, the owner checks Google Search Console. The Core Web Vitals report still shows the site as Poor. The developer says the fix worked. The owner thinks they were misled.
Both are right.
Nobody explained the 28-day window.
What Google Actually Measures, and When
To understand the window, you need to understand what Google is measuring and where that data lives.
Google’s Core Web Vitals assessment is not based on Lighthouse. It is not based on any simulation. It is based on CrUX: the Chrome User Experience Report. CrUX collects performance readings from real Chrome users who have opted into sharing that data, actual visitors on actual devices with actual connections, not a throttled simulation.
The three metrics CrUX measures are:
- LCP (Largest Contentful Paint), how long before the biggest visible element on your page appears. In business terms: when does the page feel loaded?
- INP (Interaction to Next Paint), how quickly the page responds when someone taps or clicks. In business terms: does your site feel responsive or broken?
- CLS (Cumulative Layout Shift), how much the page rearranges itself while loading. In business terms: are visitors accidentally tapping the wrong things?
CrUX does not assess each visit in isolation. It aggregates readings across a rolling 28-day window and reports the 75th percentile of that distribution. Google Developers’ documentation on PageSpeed Insights (2024) states it plainly: “PSI’s data is updated daily, while the BigQuery dataset is updated monthly. Both data sources represent trailing 28-day periods.”
DebugBear’s technical reference (2026) confirms the implication: “Google aggregates field data over a 28-day window, so changes to your website won’t be reflected immediately.”
This is not a quirk or a bug. It is an intentional design that gives the signal statistical stability. A single fast day does not override a month of slow ones.
The Math Behind the Delay
Here is what the 28-day window means in practice.
If your site has been loading slowly for three months and you fix it today, day one of the fix gets added to a window that still contains 27 days of slow data. The 75th percentile of that combined dataset will not be meaningfully different from what it was yesterday.
Each subsequent day, one slow day falls off the back of the window and one fast day joins the front. The 75th percentile shifts incrementally toward the fixed state. The rate of change depends on two factors: how dramatic the improvement was, and how much daily traffic your site receives. A high-traffic site improves faster in the data because each new fast day represents a larger number of readings.
For most SMBs with modest traffic:
- Lighthouse (lab data): shows the fix immediately. A Lighthouse run is a fresh simulation, it carries no history.
- PageSpeed Insights field data: starts updating after the fix, but the rolling window means the numbers move slowly, roughly two weeks before you see meaningful movement.
- Google Search Console CWV report: template-level aggregation from the same CrUX pool. Fully cleared status appears approximately 28 days after the last slow data exits the window.
The critical point about Lighthouse: confirming that the fix improved the Lighthouse score is a legitimate and useful step. It tells you the fix was correctly implemented. It is not, however, evidence that the site now passes Core Web Vitals. Those two things are different measurements entirely. For a full treatment of lab scores versus field data and why the distinction matters, the comparison is worth reading before you report results to anyone.
The Template Complication
There is one more layer that trips up owners and developers who understand the window but still find Search Console confusing.
Google Search Console does not report on individual URLs for Core Web Vitals. Per web.dev’s documentation (2025), “Search Console groups similar pages (for example, pages that use the same template) into a single group assessment.” That means the CWV report groups your 43 service pages together and gives them a single status based on the collective performance of the whole group.
The implication: if you fix the LCP problem on one page in the template group but leave the rest of the template unchanged, the group’s status will not clear. The whole template needs to improve before Search Console reflects a different status for that group.
This is not a Search Console error. It is the correct behavior, if your appointment booking page is fast but every other service page is still slow, your service page template genuinely has a performance problem. The grouping surfaces that accurately.
For many sites with recurring page templates, services, products, blog posts, the fix needs to happen at the template level, not the page level. This is why fixing the template is worth far more than fixing individual pages.
How to Verify a Fix Without Waiting 28 Days
The 28-day window is not an argument for blind patience. There is a tool that closes the feedback gap.
The web-vitals JavaScript library is Google’s recommended method for collecting Real User Monitoring (RUM) data from your own site. It is approximately 2KB, free, and open-source. According to web.dev (2025), implementing it is “the easiest way to collect Web Vitals measurements” for a site owner running their own RUM setup.
Once installed, you get your own stream of real-user performance data, same metrics, same users, same interactions, updated continuously rather than through CrUX’s 28-day window. If your developer deployed a fix yesterday and the library is running, you can see today whether real visitors’ LCP improved.
The Halodoc Engineering team (2024) documented a production implementation that demonstrates this: “With this setup [RUM via GA4 and GTM], enables real-time tracking of INP and other CWVs, identification of problematic elements, and deeper insights into user experience bottlenecks, eliminating the need to wait for a month to see updates on Google Search Console.”
Adding the web-vitals library before any major performance work begins is the professional-grade workaround. You implement the fix, watch the real-user data confirm it the same day, and then wait 28 days for Search Console to catch up, already knowing the answer.
This also changes the conversation with any developer doing the work. When you ask about third-party scripts and website performance, a common source of slow LCP, the right standard is not “did the Lighthouse score improve” but “is the web-vitals stream showing better real-user LCP?”
A Worked Timeline: The Dental Practice Scenario
Consider, hypothetically, a Tampa Bay dental practice whose developer optimizes the LCP image on the appointment booking page.
Day 0. Developer confirms Lighthouse shows LCP improved from 3.8 seconds to 1.9 seconds. The fix is real. A calendar reminder is set for day 28. The web-vitals library is already running, so same-day real-user data begins confirming the improvement within hours of the deploy.
Day 7. Owner checks PageSpeed Insights. The field data section still shows LCP in the “Needs improvement” range. This is expected: six days of fast data have joined the window, but 22 days of slow data are still in it. The 75th percentile has not crossed the “Good” threshold of 2.5 seconds yet.
Day 14. PSI field data is visibly moving. The LCP figure has dropped, though still not at “Good.” The web-vitals library confirms that new visitors are getting fast LCPs consistently.
Day 28. Search Console shows the “Appointment pages” template group moving from “Poor” to “Good.” The 28 days of slow data have now fully exited the rolling window. The fix is reflected in the official field data.
No drama, no confusion, no accusation that the developer lied. The 28-day window was explained at the start, and the web-vitals library provided real-time confirmation throughout.
For an understanding of why LCP is the metric most sites fail and what actually moves it, that article covers the optimization side once the diagnostic work here is done.
Setting the Right Expectation Before Work Begins
The cost of skipping the 28-day explanation is not just confusion. It is eroded trust: the owner loses confidence right at the moment when the fix is actually working. It leads to premature re-intervention, additional changes before the first fix has had time to show up, which resets the window and introduces noise.
The conversation should happen before work begins, not after someone is already frustrated.
If a fix has been deployed, the practical steps are: run the Lighthouse comparison to confirm implementation, add the web-vitals library if it is not already running, and check the PSI field data section starting around day 10. Full resolution in Search Console appears at or after day 28.
Documented Core Web Vitals revenue case studies share one thing in common: the teams running those projects knew what they were measuring and when to look for it.
A free assessment from iServU includes pulling your current CrUX field data and telling you whether what Search Console is showing reflects a real ongoing problem or the tail end of a window that is already clearing. Gabriel Lopez-Seco runs it directly. No account manager, no handoff.
Schedule a free assessment at iServU.
Sources
- Google Developers (2024). About PageSpeed Insights. https://developers.google.com/speed/docs/insights/v5/about
- DebugBear (2026). Why Lighthouse Lab Data Doesn’t Match Field Data. https://www.debugbear.com/blog/lighthouse-lab-data-not-matching-field-data
- web.dev / Google (2025). Core Web Vitals workflows with Google tools. https://web.dev/articles/vitals-tools
- Halodoc Engineering Blog (2024). Real-Time Monitoring for Core Web Vitals with GA4 and GTM. https://blogs.halodoc.io/real-time-monitoring-for-core-web-vitals-with-ga4-gtm/
- web.dev / Google (2025). Getting started with measuring Web Vitals. https://web.dev/articles/vitals-measurement-getting-started
