Do you really need to wait 30 days to see the impact of your Core Web Vitals optimizations in PageSpeed Insights?

What is the difference between field data and lab data in PageSpeed Insights?

Lab data is generated instantly by Lighthouse during a synthetic test under controlled conditions. It reflects the theoretical performance of your page at a given moment, with a simulated 4G connection and an emulated mobile device.

Field data, on the other hand, comes from the Chrome User Experience Report (CrUX). It aggregates real experiences from thousands of Chrome users over a rolling 28-day period. This second metric is what counts for ranking, but it's also the one that carries an unavoidable delay.

Why does this 30-day delay exist?

CrUX collects anonymized data from Chrome browsers for 28 consecutive days, then aggregates and publishes these statistics with a few additional days delay. If you deploy an optimization today, the first real visitors benefiting from it enter the data collection window, but previous visitors who experienced the old version continue to weigh in the average.

Only after 30 full days does 100% of the rolling window reflect the new version of your site. In the meantime, the field data mix old and new, which can muddle your understanding if you are looking for an immediate signal.

Which metrics are affected by this delay?

All Core Web Vitals metrics reported in PageSpeed Insights via CrUX experience this delay: Largest Contentful Paint (LCP), First Input Delay (FID) or Interaction to Next Paint (INP) depending on the version, and Cumulative Layout Shift (CLS).

Lab data, however, includes additional metrics like Time to Interactive or Speed Index, but they do not reflect the actual user experience. They serve as a leading indicator, not ground truth.

• Field data (CrUX): 30-day delay, aggregated real data, impact on ranking
• Lab data (Lighthouse): snapshot, synthetic conditions, useful for quick debugging
• Rolling window: 28 days of collection + a few processing days
• Affected metrics: LCP, FID/INP, CLS only for field data
• Visibility in PSI: separate tab "Discover what your real users are experiencing" for CrUX

Is this statement consistent with field observations?

Yes, and it's a welcome reminder. We regularly see clients or colleagues panicking 48 hours after a deployment because the field data in PageSpeed Insights hasn’t budged an inch. The 30-day delay has long been documented in the CrUX FAQ, but it remains unknown or underestimated.

What complicates matters is that PageSpeed Insights displays these two datasets side by side without always clarifying that one is a theoretical snapshot and the other a rolling average over four weeks. The untrained practitioner will naturally compare the two, see a huge divergence, and wonder if their optimization is working. The answer: maybe, but you will need to wait.

In what cases does this delay pose a strategic problem?

If you are working on a low-traffic site, the field data may never appear in PageSpeed Insights, even after 30 days. CrUX requires a minimum volume of Chrome visitors to publish statistics — Google does not communicate a specific threshold, but it is estimated that several thousand page views per month are needed. [To be verified]: no official figure has been provided by Google regarding this minimum.

Another problematic scenario is highly seasonal sites. If you deploy an optimization in January and your peak traffic occurs in December, you risk missing representative data for months. The field data from January will not reflect the actual load the site will undergo during peak season.

What nuances should be added to this recommendation?

Mueller suggests using lab data for a quick check, then waiting 30 days. This is pragmatic, but incomplete. Lab data tests an isolated page, under ideal conditions, without considering third-party scripts, real network variations, or user behavior (scrolling, clicks). A good Lighthouse score does not guarantee a good CrUX.

There is a missing link: homegrown RUM (Real User Monitoring) tests, through tools like SpeedCurve, Datadog RUM, or even the web-vitals API in JavaScript. This allows you to track your Core Web Vitals in near real-time on your own analytics, without waiting for Google to aggregate. This is what enables the detection of a regression within hours, not in 30 days.

What should you do concretely before and after an optimization deployment?

Before any deployment, take a snapshot of your current metrics: CrUX field data in PageSpeed Insights, but also in Search Console (Core Web Vitals report) and, if possible, in a proprietary RUM tool. Note the exact date of deployment.

Immediately after, run several Lighthouse tests on representative pages. If lab data does not improve, it means your optimization did not work as expected — no need to wait 30 days to find out. If lab data progresses, you have a quick positive signal, but not definitive.

How to interpret the discrepancies between lab and field data during the transition period?

Between Day+1 and Day+30, field data will evolve gradually, but not linearly. You may see a slight improvement on Day+15, followed by stagnation, and then a new leap on Day+28. This is normal: the rolling window gradually incorporates the new version.

If at the end of Day+30 the field data still do not match the lab data, there are several hypotheses: mobile vs desktop traffic (CrUX aggregates across all devices, Lighthouse tests mobile by default), third-party scripts not present in lab, CDN cache that takes time to purge, or worse, an invisible regression in lab but real on some user segments (older browsers, residual 3G connections). Investigate with a RUM.

What mistakes should be avoided during this waiting period?

Do not deploy five successive optimizations at three-day intervals. You will never be able to untangle what worked. Space your iterations by at least 30 days if you want to isolate the effects in the field data, or else accept to measure only the cumulative impact.

Another trap: relying solely on aggregated field data at the origin level (the entire site). PageSpeed Insights and CrUX allow filtering by URL or group of URLs if volume permits. A homepage may show excellent LCP while product pages remain catastrophic. Segment your analyses by page type.

• Take a complete snapshot of CrUX metrics before deployment (PageSpeed Insights + Search Console)
• Test immediately in lab after deployment to verify that the optimization works theoretically
• Implement a homegrown RUM monitoring if possible, for near real-time tracking
• Space optimization deployments by 30 days if you want to measure the isolated impact of each
• Compare field data by page group (homepage, product sheets, blog) and not just at the site level
• Wait 30 full days before drawing definitive conclusions on the real impact