Why does Google measure Core Web Vitals on the actual page version your visitors are really viewing?

Which page version does Google consider for Core Web Vitals?

Google does not measure Core Web Vitals on a theoretical version of your page, but on the one that real users predominantly view. If your site offers an AMP version and a standard HTML version, the engine will analyze the one that receives the most traffic.

This logic changes the game for dual-stack sites. Until now, many practitioners thought that Google would systematically evaluate the canonical version. False. The traffic distribution becomes a decisive factor in performance measurement that will influence ranking.

How can I know which version will be evaluated for my site?

Check your server logs or your analytics tool: which version predominantly serves your visitors? If 70% of your Google traffic comes to AMP via the mobile carousel and 30% to HTML desktop, it’s the AMP performance that will count in the calculation of Core Web Vitals.

The problem is that this mix can vary by sector, devices, countries. An e-commerce site with a strong desktop audience will have a very different profile than a very mobile news media. Google does not provide any specific thresholds: is it 51% that makes the shift happen? 60%? We navigate by sight.

What does this approach reveal about Google’s strategy?

By focusing on the real user experience, Google aligns its ranking criteria with what internet users actually experience. This is consistent with the philosophy of Core Web Vitals: to measure what truly impacts UX, not what a Lighthouse audit shows in a lab.

This statement also confirms that Google continues to push AMP as the preferred format for mobile. If your AMP is predominant and efficient, you win. If it's predominant but slow, you lose. No half measures.

• Google measures the page version predominantly viewed by real users (AMP or standard HTML).
• The traffic distribution between versions becomes an indirect ranking factor via Core Web Vitals.
• No specific thresholds have been communicated to determine which version is "predominant".
• Dual-stack sites must audit their traffic mix to anticipate which version will be evaluated.
• This approach emphasizes the importance of optimizing the version that actually serves the most visitors, not necessarily the canonical.

Is this statement consistent with observed practices on the ground?

Yes, and it's even a rare case of welcome transparency. Google confirms what the data from CrUX already showed: the metrics reported come from real Chrome traffic, not from a crawler. It makes sense that the predominantly viewed version weighs more heavily.

However, we observe a significant gap between AMP and standard HTML performance on some sites. A media client had an AMP at 95/100 Lighthouse and standard desktop HTML at 62. If traffic shifts towards desktop (change in usage, decline of AMP carousel), the Core Web Vitals score will plummet. Google says nothing about the temporal stability of this measure.

What nuances should be added to this statement?

First nuance: Google talks about “predominantly viewed version” but does not specify the time frame nor the geographic granularity. Is it an average over 28 days like CrUX? By device? By country? [To verify] by cross-checking Search Console and CrUX data.

Second nuance: this logic assumes that your site has a stable AMP/HTML mix. If you're rolling out a progressive redesign, moving from 20% to 80% HTML traffic over 3 months, the evaluated version will shift — and potentially cause fluctuations in your ranking during the transition. No official communication on this scenario.

In what scenarios might this rule create side effects?

Imagine a site with an ultra-fast AMP but a terrible desktop HTML. As long as mobile traffic predominates, everything is fine. The day Google changes the display of the AMP carousel (it happens) or a desktop competitor gains market share, traffic shifts — and your Core Web Vitals plummet.

Another case: sites with complex user journeys (progressive web app, single-page application). Google says nothing about multi-page sessions or AJAX navigations. If a user loads the AMP and then navigates in HTML via an internal link, which version counts? Silence.

What steps should you take to ensure you're measuring the right version?

Your first instinct: segment your traffic in Google Analytics or your log tool. Create “AMP” vs “standard HTML” segments and calculate the distribution over the last 28 days (the likely reference period for CrUX). If the distribution is 70/30, you know which version to focus your optimization efforts on.

Next, cross-check with CrUX data via PageSpeed Insights or BigQuery. Ensure that the LCP, FID, CLS metrics reported align with the predominantly viewed version. If you see a discrepancy between your internal RUM measurements and CrUX, it might be that Google is evaluating a different version than you thought.

What common mistakes should be avoided when optimizing multi-version Core Web Vitals?

Classic mistake: optimizing solely the canonical version thinking it’s the one that will count. If your canonical is in HTML but 80% of traffic comes to AMP, you’re missing the point. First, audit the real mix before investing resources.

Second pitfall: neglecting the coherence of user journeys. A user who lands on a fast AMP and then clicks to a slow HTML page will have a degraded experience — and Google will see that in session metrics. Think complete journey, not isolated page.

How can you track the evolution of this distribution over time?

Set up an automated dashboard that tracks the AMP/HTML ratio weekly. If you observe a shift (e.g., changing from 60/40 to 40/60), anticipate the impact on your Core Web Vitals before the ranking changes.

Also keep an eye on Google announcements about changes in AMP display (carousel, stories, etc.). A change in how results are presented can redistribute traffic between versions — and thus modify the version evaluated for Core Web Vitals.

• Segment your traffic analytics to identify the predominantly viewed version (AMP vs HTML).
• Cross-check this data with CrUX metrics to verify consistency.
• Prioritize optimizing the version that serves the most real traffic, not necessarily the canonical.
• Do not neglect the minority version: 40% of visitors with a degraded experience remains a business problem.
• Automate tracking the AMP/HTML ratio to anticipate shifts.
• Test Core Web Vitals on both versions under real conditions (devices, networks, geos).