Does AMP's Core Web Vitals rely on Google's cache or your origin server?

Why does Google measure performance through the AMP cache instead of the origin server? There are some key reasons.<\/h3>

Google's logic is straightforward: real user experience takes precedence over everything else. When a user clicks on an AMP result in mobile SERPs, they land on a page served from the Google AMP cache, not directly from your infrastructure. It is this version — the one they are actually viewing — that will have its performance measured for Core Web Vitals.<\/p>

This approach may seem obvious, but it has direct implications for SEOs who optimize their servers without considering the AMP architecture. If your AMP pages are valid, Google’s cache becomes the final delivery point. You could have a super-fast server, a premium CDN, a server response time of 50 ms — none of this matters if the AMP cache serves the page.<\/p>

How does Google’s AMP cache actually work? What do you need to know?<\/h3>

The AMP cache is a content delivery system managed by Google itself. When an AMP page is valid according to specifications, Google caches it and serves it directly from its infrastructure. This means the URL changes: your domain disappears in favor of a Google domain (cdn.ampproject.org or google.com/amp/…).<\/p>

This caching generally provides substantial performance gains: reduced latency due to Google's global network, optimized compression, pre-rendering in some cases. However, it also means you lose some control over delivery. HTTP headers, server configuration, backend optimizations — all of this becomes invisible. What Google measures is solely what reaches the browser from the cache.<\/p>

What are the differences between CWV measured on AMP cache vs traditional server? Let's explore.<\/h3>

The Core Web Vitals (LCP, FID, CLS) are calculated from real browsing data collected via the Chrome User Experience Report (CrUX). If your AMP pages are mostly served via cache, it's this cached URL that shows up in CrUX, not your original URL.<\/p>

This creates a clear distinction: your standard (non-AMP) pages are assessed on your infrastructure, while your AMP pages are evaluated on Google's. Optimization strategies differ. On AMP, you cannot influence the Time to First Byte (TTFB) of your server, nor the configuration of your reverse proxy. However, you maintain control over the HTML structure, resource weight, AMP JavaScript, and layout (CLS).<\/p>

• Google's AMP cache effectively becomes the origin server for calculating Core Web Vitals if your AMP pages are valid.<\/li>
• Traditional server optimizations (TTFB, connection management, compression) no longer apply to cached AMP pages.<\/li>
• CrUX reports data for the URL served to the browser, so the cached AMP URL, not your original domain.<\/li>
• You remain in control of the HTML structure, embedded resources, images, AMP CSS, and therefore LCP and CLS.<\/li>
• FID is generally excellent on AMP thanks to the JavaScript restrictions imposed by the format.<\/li><\/ul>

Is this statement consistent with observed practices on the ground? Let's delve deeper.<\/h3>

Yes, and it's confirmed by CrUX feedback. When you query the CrUX API or PageSpeed Insights for a cached AMP URL, it is indeed the cached URL that appears in the results, not your domain. Google measures what the user sees, period. No double counting, no averaging between cache and origin.<\/p>

That said, many SEO practitioners still underestimate this reality. They optimize their backend, reduce their TTFB to 30 ms, configure HTTP/3 early hints — and wonder why their AMP pages aren’t performing well in Core Web Vitals. The answer is simple: those optimizations don’t count if the AMP cache takes over. The real gain lies elsewhere: image weight, DOM structure, visual stability.<\/p>

What nuances should we add to Mueller's statement? Let's clarify a few points.<\/h3>

The statement is clear, but it masks a complexity: not all AMP pages automatically go through the cache. If your AMP page contains validation errors, it won't be cached by Google. In that case, your origin server serves the page, and Core Web Vitals are measured on your standard infrastructure.<\/p>

Another point: the AMP cache isn’t eternal. There is a time-to-live (TTL) for cached pages, usually short (a few minutes to a few hours depending on resources). If your page has low traffic, it may be purged from the cache and reload from the origin on the next visit. In this case, the measured performance temporarily shifts back to your server. [To verify]: Google does not document TTL and cache purge rules precisely, making it difficult to predict what percentage of traffic actually goes through the cache on sites with variable audiences.<\/p>

When does this rule not apply? Let's identify exceptions.<\/h3>

First obvious case: invalid AMP pages. If the AMP validator raises errors, your page won’t be cached. Google will serve it directly from your server, and Core Web Vitals will be measured on your infrastructure. This is a common trap: an invisible validation error can derail your entire CWV strategy.<\/p>

Second case: AMP on custom domain with Signed Exchanges. With the advent of Signed Exchanges (SXG), it’s possible to serve AMP pages from your own domain while still benefiting from Google preloading. In this setup, it’s your URL that appears in the address bar, and Core Web Vitals are measured on that URL. But be cautious, SXG imposes strict constraints (certificate, HTTP headers, validity duration) and is not trivial to implement.<\/p>

Warning: If you switch from classic AMP (cached) to AMP with Signed Exchanges, your CrUX data may fragment between the cached URL and the custom URL. This transition can create a temporary apparent drop in metrics until the new data replaces the old ones in CrUX (28-day sliding window).

What practical steps should you take to optimize CWV on AMP? Let’s get started.<\/h3>

First step: validate that your AMP pages are indeed cached. Use Google's AMP testing tool in Search Console or directly test a cached URL (format cdn.ampproject.org). If validation errors appear, prioritize fixing them. An invalid AMP page will never be cached and therefore never eligible for Google’s performance optimizations.<\/p>

Next, focus on levers you can actually control: image weight (use amp-img with srcset and modern formats like WebP/AVIF), visual stability (always set width and height on images and iframes to avoid CLS), and loading priority (identify your LCP element and ensure it loads quickly without being blocked by third-party resources). Forget about TTFB, forget about backend — it's no longer your concern on cached AMP.<\/p>

What mistakes should you absolutely avoid in an AMP CWV strategy? Let's explore the pitfalls.<\/h3>

Mistake #1: optimizing the origin server while ignoring the AMP cache. Investing in a premium CDN, a super-fast server, an optimized reverse proxy — all this is pointless if your valid AMP pages are being served through Google’s cache. You’re spending money to optimize a passage point that Google bypasses.<\/p>

Mistake #2: not monitoring CrUX data by origin. If you have both AMP and non-AMP pages, your CWV data will be fragmented. The cached AMP URL and the classic URL are two distinct origins in CrUX. You must track both separately, or you risk misinterpreting your overall performance. Mistake #3: neglecting AMP validation. A single syntax error is enough to push a page out of the cache, thereby degrading your CWV measured on your origin server, which may be less performant.

How can I check if my AMP site is truly benefiting from Google's cache? Let's find out.

Test an AMP URL directly in the official AMP validator (validator.ampproject.org) or via Google Search Console, section "AMP". If the page is valid, it is eligible for caching. To confirm that it is actually cached, search for it in Google on mobile and inspect the served URL: if it starts with cdn.ampproject.org or google.com/amp/, you're good to go.<\/p>

You can also use the CrUX API to directly query the cached URL and check the retrieved metrics. If CrUX returns no data for the cached URL, either your traffic is too low (CrUX requires a minimum volume), or the page is not being served in cache. Finally, monitor your Core Web Vitals in Search Console: if you see two distinct URL groups (AMP cache vs origin), it's a clear signal that some pages are escaping the cache, likely due to validation errors.<\/p>

• Validate all AMP pages with the official tool and fix errors blocking caching.<\/li>
• Optimize image weight and format (WebP/AVIF, srcset, native AMP lazy loading).
• Set width and height on all visual elements to stabilize CLS.
• Identify the LCP element (usually a hero image) and prioritize it with fetchpriority="high" if supported.
• Monitor CrUX data separately for cached AMP URLs and standard URLs.
• Do not invest in backend server optimizations for valid cached AMP pages — it's a waste.
<\/ul>
Optimizing Core Web Vitals on AMP requires a different approach from classic strategies. Google's AMP cache essentially becomes your effective origin server, shifting the focus from backend optimizations (TTFB, infrastructure) to frontend optimizations (images, visual stability, HTML structure). These optimizations may seem straightforward on paper, but their implementation at scale — especially on sites with thousands of AMP pages — demands sharp technical expertise and rigorous monitoring. If your organization lacks internal resources specialized in AMP and Core Web Vitals, it may be wise to collaborate with an experienced SEO agency to audit your implementation, identify quick wins, and ensure long-term compliance.