Does the Chrome UX Report really count your cached AMP pages?

Why does Google collect data from the AMP cache?

The Chrome UX Report measures real user experience (RUM) on Chrome. When a user accesses your content via an AMP page served from cdn.ampproject.org , it is this cached version that is measured — not your original page.

This distinction has a direct impact on your Core Web Vitals . If your AMP is valid and cached, you benefit from the optimized performance of Google's cache. If it's invalid, Google cannot serve it from the cache, the user sees your canonical version, and the CrUX metrics reflect this version (often slower).

What constitutes a 'valid' AMP page according to Google?

A valid AMP page meets all AMP technical specifications : allowed tags, JavaScript disallowed except for official AMP components, inline CSS limited to 75 KB, etc. Google validates each crawled AMP page before caching it.

As soon as a validation error appears — an unauthorized tag, an external script, a syntax error — the page cannot be served from the cache. The user lands on your canonical version, and this is the version CrUX measures .

How does this impact my Core Web Vitals data?

If your AMP is valid and cached, your CrUX metrics reflect the exceptional performance of Google's cache : ultra-fast LCP, minimal CLS, negligible FID. These scores artificially inflate your Core Web Vitals for AMP URLs.

But if your AMP is invalid, CrUX measures your canonical page — likely heavier and slower. You lose the AMP cache performance benefit, and your Core Web Vitals deteriorate . Worse: you may not even know that your AMP is broken.

• CrUX uses data from the version actually served : cached AMP if valid, canonical otherwise.
• An invalid AMP robs you of the performance boost of Google's cache in CrUX.
• The Core Web Vitals measured can differ drastically between valid AMP and broken AMP.
• Google does not always alert you if your AMP becomes invalid after publication.
• Regularly check AMP validity with the official tool or Search Console.

Does this statement align with field observations?

Yes, and it is consistent with practitioners’ reports. Many have noticed massive discrepancies in Core Web Vitals between their AMP and canonical URLs. When the AMP is valid and cached, the CrUX metrics are green; as soon as a validation error appears, the scores plunge.

The problem? Google does not always immediately notify that an AMP has become invalid. You could serve a slow canonical version for weeks, thinking your AMP is working, and see your Core Web Vitals decline without understanding why . [To verify] : no public data specifies the CrUX update delay after AMP invalidation.

What nuances should be added to this statement?

Mueller simplifies slightly. In reality, CrUX aggregates data on 28 rolling days . If your AMP becomes invalid mid-month, your CrUX metrics will continue to mix cached AMP data (old) and canonical data (recent) for several weeks.

Another nuance: not all users go through the AMP cache. Those who access your canonical URL directly (via desktop search, link sharing, etc.) generate CrUX data based on that version, even if your AMP is valid . CrUX aggregates both, but Google does not precisely document the ratio.

In what cases does this rule not apply?

If you do not have an AMP version, this statement is obviously irrelevant. But let’s be honest: many sites have abandoned AMP since Google removed the AMP badge from mobile SERPs and broadened Top Stories eligibility to non-AMP pages.

If your site has removed its AMPs without proper 301 redirection , you may still have indexed AMP URLs generating 404s or errors. These broken pages do not appear in CrUX, but they clutter your index and create confusion. [To verify] : the exact impact of orphaned AMPs on crawl budget remains unclear.

What should you concretely check on your AMP pages?

Start by auditing the validity of each AMP page with the official AMP Validator tool or via Search Console (page experience report). A single error is enough to block caching. Inspect especially dynamic templates: a third-party component added in production can break all your AMPs at once.

Next, ensure your AMP URLs appear in CrUX. Check the Core Web Vitals report on Search Console and compare AMP vs canonical metrics . If AMPs do not appear or show identical scores to the canonical, they are likely not being served from the cache.

What configuration errors most often break AMPs?

Classic culprits include: third-party JavaScript scripts mistakenly embedded (non-AMP analytics, custom ads), <style> tags out of norms, outdated non-updated AMP components, inline CSS exceeding 75 KB, non-AMP iframes, or disallowed HTML5 tags (e.g., <video> without amp-video component).

Another frequent pitfall: badly configured internal redirects . If your AMP redirects to the canonical (configuration error), Google cannot serve it from the cache, and CrUX measures the canonical instead. Result: you lose performance benefits without even realizing it.

How to continuously monitor AMP validity?

Set up Search Console alerts on the AMP report to be notified of validation errors. Integrate the AMP Validator test into your CI/CD pipeline: each deployment should automatically validate AMP templates before going live.

Also monitor your CrUX metrics via BigQuery (free CrUX export). If you notice a sudden drop in performance on your AMP URLs , it's often a sign of recent invalidation. And this is where it gets complex: diagnosing why an AMP has become invalid requires sharp technical expertise.

• Audit AMP validity with the official tool or Search Console monthly.
• Compare AMP vs canonical Core Web Vitals in Search Console.
• Remove all non-AMP third-party JavaScript scripts from your templates.
• Ensure your inline CSS stays under 75 KB after every update.
• Set up Search Console alerts on the AMP report.
• Test each deployment with AMP Validator in pre-production.