How does Google now assign AMP cache's CrUX data to the origin?

What does this consolidation of CrUX data change for the AMP cache?

Until now, AMP cache CrUX data was treated separately from that of your main origin. Google's AMP cache served your pages from its own servers (cdn.ampproject.org), creating a distinct technical origin. The result: your performance metrics were fragmented.

Now, Google attributes this data to your canonical origin. If a user loads your article via the AMP cache, their Core Web Vitals (LCP, FID, CLS) metrics show up in the CrUX report for your main domain. The artificial separation is gone.

Why is correct canonicalization the key?

Google emphasizes a crucial point: canonicalization must be bidirectional. Your AMP page should point to the non-AMP version via <link rel="canonical">, and vice versa with <link rel="amphtml">. Without this configuration, Google cannot link the two versions.

In practice, a clunky canonicalization was already problematic for indexing. Now, it also deprives you of the consolidation of CrUX metrics. If your AMP pages generate significant traffic but the canonical tags are broken, your performance data remains orphaned.

Which CrUX metrics are affected by this attribution?

All Core Web Vitals from the CrUX dataset are aggregated: Largest Contentful Paint, First Input Delay (or Interaction to Next Paint), Cumulative Layout Shift, First Contentful Paint, Time to First Byte. This data comes from real Chrome users, collected over the past 28 rolling days.

The impact is direct on your Page Experience assessment. Google uses CrUX to determine whether your pages meet the "good" thresholds of Core Web Vitals. If your AMP pages are ultra-performing (which is often the case due to the constraints of the format), they can offset slower desktop or mobile versions.

• AMP cache CrUX data is now counted in the metrics of your main origin
• Bidirectional canonicalization (AMP to non-AMP and vice versa) is required for attribution to work
• All Core Web Vitals are affected, with a direct impact on the Page Experience assessment
• High-performing AMP traffic can now boost your overall CrUX metrics instead of being isolated
• The 28 rolling days of the CrUX dataset now include data from both versions if the configuration is correct

Does this announcement really address the historical issue of AMP fragmentation?

Let’s be honest: this is a technical adjustment long awaited. The separation of AMP/non-AMP origins was an architectural artifact that made no sense from a UX perspective. A user engages with your content, whether Google serves it from its cache or your server.

But here's the hitch — [To be verified]: Google doesn't specify the weighting applied when metrics diverge significantly between AMP and non-AMP. If 70% of your mobile traffic comes from the ultra-fast AMP cache and 30% from your standard slower mobile version, how does CrUX aggregate? Proportional ratio to actual traffic volume? Arithmetic mean? No clarification.

In what scenarios can this consolidation skew your performance diagnosis?

Imagine your AMP pages show an LCP of 1.2 seconds (excellent) but your non-AMP mobile version maxes out at 3.8 seconds (poor). After consolidation, your overall CrUX report may show an "average" LCP of 2.0-2.5 seconds, depending on traffic distribution.

The risk? Masking real performance issues on your main version. You could turn green in CrUX thanks to the AMP leverage while leaving your standard mobile site sluggish. For an accurate audit, you now need to cross-reference CrUX data from the origin with your RUM (Real User Monitoring) metrics by page type.

Is Google consistent with its long-term strategy on AMP?

This announcement comes as AMP has not been a requirement for Top Stories since 2021. Google has deprioritized the format, acknowledging that Core Web Vitals alone suffice. Consolidating CrUX data is implicitly admitting that the separation of origins was a design mistake.

Paradoxically, this may rekindle interest in AMP — not as an imposed format, but as a CrUX metrics optimizer. If you maintain AMP for part of your traffic (especially mobile), you benefit from an aggregated performance boost. Viable strategy? Yes, if you have the resources to maintain two versions. Otherwise, it's better to optimize your single version.

What should you prioritize checking on your AMP setup?

First reflex: audit your canonical tags. Crawl your site with Screaming Frog or Oncrawl isolating AMP pages. Check that each AMP page contains <link rel="canonical" href="https://yoursite.com/page"> pointing to the non-AMP version. Then check the reverse: each non-AMP page must have <link rel="amphtml" href="https://yoursite.com/page/amp">.

Next, verify in Search Console that Google is indexing the correct canonicals. Go to Coverage > Excluded > "Alternative page with appropriate canonical tag". Your AMP pages should be listed there, confirming that Google understands the hierarchy. If they appear in indexed pages, you have a canonicalization issue.

How to measure the actual impact of this CrUX consolidation?

Compare your CrUX data before/after in PageSpeed Insights or the Core Web Vitals report in Search Console. Note the date of this change deployment by Google, then observe the metrics evolution over the following 28 days (the duration of the CrUX window).

Also, set up a segmented RUM monitoring (Google Analytics 4 with Web Vitals or a tool like SpeedCurve). Filter your data by page type (AMP vs non-AMP) to understand the real contribution of each version to your overall metrics. If AMP represents 5% of traffic, the impact will be marginal. If it weighs 40%+, it's significant.

Should you maintain AMP solely to optimize CrUX?

Legitimate question. If your AMP traffic is substantial (typically media, news, recipes) and your AMP versions vastly outperform, keeping the format makes sense. You gain CrUX points effortlessly since AMP already imposes strict performance constraints.

On the other hand, if you're generating