Do Core Web Vitals really measure what your users actually see?

Which page version does Google consider for Core Web Vitals?

Google measures Core Web Vitals on the version that actually displays in the user's browser. If your site offers a AMP version and that’s the one that loads from the search results, it’s this AMP version that will be evaluated. If the user lands on the classic HTML version, that’s what counts.

This logic follows the principle of real user experience: Google does not measure a theoretical or technical version, but rather what people actually see. The data reported via the Chrome User Experience Report (CrUX) reflects this on-the-ground reality, not a controlled test environment.

Why is this distinction important for AMP sites?

Many sites have deployed AMP to benefit from priority display in mobile carousels or to improve their perceived speed. But if most organic traffic lands on AMP, then performance optimizations on the classic HTML version become secondary for the ranking related to Core Web Vitals.

Conversely, if your strategy is to abandon AMP and go all in on a highly optimized HTML version, you must ensure that it’s this version that users are loading. Otherwise, you are optimizing the wrong target. The consistency between technical setup and actual traffic becomes critical.

How does Google collect this real performance data?

Core Web Vitals are measured through CrUX, which aggregates anonymous browsing data from Chrome users. Each visit generates metrics (LCP, FID, CLS) that are associated with the URL actually loaded. If a user arrives at example.com/amp/article, it is this URL that will be evaluated.

This ground-level approach means that performance variations based on devices, connections, and geographies are taken into account. A site may perform differently on 4G mobile in India compared to fiber desktop in France—Google measures both realities, not a single synthetic score.

• AMP Version: measured if that’s what the user actually loads from the SERPs
• Classic HTML Version: measured if it is the default displayed version
• CrUX: collects data on the actual URL visited, not a theoretical version
• Real Traffic: metrics reflect the experience of real users, not lab tests
• Strategic Consistency: optimizing a version that no one sees does nothing for ranking

Is this statement consistent with observed practices on the ground?

Yes, and it is even one of the few cases where Google applies exactly what it states. The publicly available CrUX data clearly shows that AMP and non-AMP URLs are tracked separately. If you compare the metrics for example.com/article and example.com/amp/article in the CrUX report, you will see two distinct lines with often very different performances.

What complicates things is that many sites assumed optimizing their HTML version would suffice, while 90% of their mobile traffic was landing on AMP without their realization. The awakening was harsh when Core Web Vitals became a ranking factor— their AMP version, never optimized, dragged the entire site down.

What nuances should be brought to this rule?

Mueller's statement is clear on the surface, but it says nothing about the traffic thresholds required for a URL to be included in CrUX. A page with 10 visits per month does not generate enough data to be evaluated—Google then relies on metrics at the domain or origin level.

Another vague point: what happens when a site offers both AMP and classic HTML, but users are split 50/50 between the two versions? Does Google aggregate the scores? Does it take the dominant version? [To be verified]—the official documentation remains vague on this point, and ground feedback is contradictory.

In what cases can this logic create problems?

The most insidious case: a site that abandons AMP without properly redirecting the old AMP URLs to the HTML versions. If Google continues to serve cached AMP URLs (or if backlinks point to them), these ghost pages continue to be measured and negatively impact the overall Core Web Vitals of the domain.

Another trap: sites that test their performance with Lighthouse or PageSpeed Insights on the HTML version, achieve perfect scores, and don’t understand why their ranking isn’t changing. However, their real users are loading a non-optimized AMP version—and that’s what CrUX measures. Testing the wrong version is the classic error here.

What should you do if your site uses AMP?

First, check which version is actually served to your users. Consult your server logs or filtered Google Analytics for mobile organic traffic: how many URLs contain /amp/ or an AMP parameter? If it’s the majority, it’s this version that should be prioritized for optimization.

Next, test the Core Web Vitals of your AMP version with PageSpeed Insights by directly pasting the AMP URL. Do not solely rely on the HTML version scores—they do not reflect what Google measures if no one visits it. Compare LCP, CLS, and FID between the two versions and focus your efforts where the real traffic lies.

How to manage a migration from AMP to classic HTML without losing performance?

If you decide to abandon AMP, the transition must be gradual and monitored. First, remove the rel="amphtml" tags from your canonical pages so that Google stops offering the AMP version. Set up clean 301 redirects from the AMP URLs to the HTML URLs.

Then, monitor CrUX for at least a full month. Data takes time to switch—Google continues to measure the old AMP URLs as long as they receive residual traffic (backlinks, cache, bookmarks). If your Core Web Vitals drop after migration, it’s often because the HTML version is not as performant as you thought.

What errors should you avoid when optimizing Core Web Vitals?

The number one mistake: optimizing the version that no one sees. Before launching an optimization project, confirm which URL is primarily loaded by your users. Do not assume it’s the HTML version—check with real data.

Second trap: believing that lab tests (Lighthouse) are sufficient. These tools measure a theoretical version under ideal conditions. The CrUX data reflects the real world: slow connections, low-end devices, outdated browsers. A Lighthouse score of 95 does not guarantee green Core Web Vitals if your real users are on 3G with a budget smartphone.

• Identify which version (AMP or HTML) is actually receiving your organic traffic
• Test the Core Web Vitals of the version that is actually served, not the one you prefer
• If migrating from AMP to HTML, implement clean 301 redirects
• Monitor CrUX for 28 days after any migration to confirm the switch
• Do not solely rely on Lighthouse scores—consult the CrUX ground data
• Compare performance between desktop and mobile, as they can diverge significantly