Do Core Web Vitals truly reflect your users' experience?

What’s the difference between field data and lab data?

Lab data (Lighthouse, PageSpeed Insights in simulation mode) measures performance in a controlled environment: stable connection, standardized hardware, empty cache. Useful for identifying issues, but they do not reflect the reality of your visitors.

Field data (Chrome User Experience Report or CrUX) aggregates metrics collected from millions of real Chrome users, with their slow connections, old smartphones, and browser extensions. This is what Google uses to evaluate your Core Web Vitals in production — and therefore for ranking.

Why is there a focus on AMP pages and caching?

When your AMP pages are served through Google's AMP cache , it’s the cached URL that is measured in CrUX — not your original domain. The AMP cache heavily optimizes loading (prerendering, preconnection, aggressive compression), resulting in excellent CWV scores.

But beware: if your AMP pages are invalid or served directly from your server, they do not go through the cache. In this case, your infrastructure will be measured , with all its potential flaws. Strict AMP validation thus becomes a prerequisite to benefit from this acceleration.

How does Google collect this real user data?

The CrUX report aggregates metrics from Chrome users who have opted in for usage statistics sharing . Only pages with sufficient traffic volume appear in CrUX — about 28 days of rolling data.

If your site lacks Chrome traffic, Google may resort to domain-level data (aggregation of all pages) or may not have any data at all. In this latter case, your CWV will technically not be considered for ranking, but you also lose the competitive advantage associated with an optimized experience.

• Prioritize CrUX data : it’s what determines your ranking, not Lighthouse scores.
• Strictly validate your AMP pages if you want to benefit from the cache — a single error blocks everything.
• Monitor PageSpeed Insights under the “Field Data” tab to see what Google is really measuring.
• Generate Chrome traffic : without sufficient volume, you won’t have CrUX data and will lose the ranking effect of CWV.
• Don’t rely on lab tests to predict your actual CWV : field conditions vary greatly among users.

Is this statement consistent with observed practices?

Yes, and it confirms what many field experts have found: clients obsessed with their Lighthouse scores of 100/100 do not always see ranking gains, while those optimizing for CrUX move ahead . The AMP nuance is also consistent — we regularly see AMP sites with excellent CWV due to caching but catastrophic performance on canonical versions.

The problem is that this statement remains deliberately vague about the exact thresholds . Google talks about ‘good,’ ‘needs improvement,’ ‘poor,’ but the boundaries shift. The current 75th percentiles (LCP < 2.5s, FID < 100ms, CLS < 0.1) are recommendations, not guarantees. [To verify] : the real impact of each metric on ranking remains opaque.

What nuances need to be addressed regarding AMP caching?

Serving via the AMP cache means delegating performance to Google . You gain speed, but lose control: it’s impossible to inject third-party JavaScript, finely customize the experience, or track with your usual tools. For an e-commerce or SaaS site, this is often a dealbreaker.

Another point: if Google decides one day to deprioritize AMP (which it has already done by removing the lightning badge from mobile results), you find yourself with an entire technical stack to maintain for uncertain benefits. The cache improves CWV, but does not compensate for weak content or a shaky SEO architecture.

In what cases does this rule not really apply?

If your site has not enough Chrome traffic , CrUX has no data about you. Google then falls back on domain-level aggregated data, or may have nothing at all. In this case, your CWV simply do not count — you are evaluated on other criteria (content, backlinks, freshness).

Another edge case: pages behind a login or paywall . CrUX only collects public pages accessible to Chrome. If a significant part of your site is private, your measured CWV reflect only a fraction of the actual experience. And for multilingual or multi-country sites, CrUX sometimes poorly aggregates data — a fast page in France may be slow in Brazil, but Google does not always distinguish fine enough.

What concrete steps should be taken to optimize field CWV?

Forget the obsession with a perfect Lighthouse score. Focus on PageSpeed Insights under the “Field Data” tab : this is where you see your real CrUX CWV. If you are in the green (good) for all three metrics at the 75th percentile, you’re good. If you’re orange or red, prioritize actions that affect real user perception .

For AMP, validate each page with the official validator before publication. A minor error (missing attribute, prohibited tag) is enough to block the cache. Use Google Search Console’s AMP Test Tools to check if your pages are eligible for the cache. If they are, monitor the CWV on the cached URL, not on your original domain.

What mistakes should be avoided when trying to improve CWV?

Do not rely on lab tests to predict your CrUX results. A Lighthouse score of 95 guarantees nothing if your real users have 3G connections and entry-level smartphones. Test on real devices , with network throttling, to approximate field conditions.

Another trap: only optimizing the homepage. CrUX evaluates all pages with traffic . If your product pages or blog articles are slow, they drag down your overall metrics. Prioritize high-traffic templates, not just the homepage.

How can I check if my site is benefiting from the AMP cache?

In Google Search Console, section Experience , check that your AMP pages are listed as ‘valid.’ Then, in PageSpeed Insights, test the AMP cache URL (format https://cdn.ampproject.org/c/s/yourdomain.com/page ) to see the measured CWV. If scores are excellent on the cache but mediocre on your domain, it means the cache is doing its job.

Also use the AMP Cache Viewer to inspect what Google is actually serving. Sometimes, a page seems valid but is not cached for obscure reasons (misconfigured HTTP headers, blocking robots.txt). In this case, field CWV will not benefit from any acceleration.

• Monitor CrUX in PageSpeed Insights under the “Field Data” tab, not lab scores
• Strictly validate your AMP pages with official tools before publication
• Test CWV on real devices and connections, not just on WiFi on a MacBook
• Prioritize high-traffic templates (product pages, articles) to maximize CrUX impact
• Ensure your AMP pages are served via the cache, not directly from your server
• Don’t count on AMP as a miracle solution — optimize the canonical version as well
Optimizing real Core Web Vitals requires a field approach, not lab-based. If you use AMP, strict validation is essential to benefit from caching. Monitoring CrUX becomes more important than scoring 100 on Lighthouse. These optimizations can be complex to orchestrate alone, especially on high-traffic sites or with heterogeneous tech stacks. Consulting a specialized SEO agency can speed up diagnostics and ensure measurable improvements without the risk of technical regression.