Should AMP pages really adhere to the same Core Web Vitals thresholds as standard HTML pages?

Why does this clarification change the game for AMP?

For a long time, SEO practitioners viewed AMP as an automatic ticket to web performance. The logic seemed simple: a framework constrained by design, limited resources, hence metrics would inevitably be green.

This statement from Mueller shatters that assumption. AMP is not a wild card that exempts one from rigorous CWV auditing. Google applies exactly the same thresholds — 2.5s for LCP, 100ms for FID, 0.1 for CLS — whether it's an AMP page or a vanilla HTML page with 3MB of JavaScript.

Where are the friction points on AMP?

The majority of AMP pages do indeed meet the thresholds without particular effort. The framework imposes strict constraints: no custom JavaScript without going through validated components, CSS inline limited to 75KB, native lazy-loading on images.

However, three scenarios create recurring problems. First, third-party ads: a poorly configured programmatic slot can spike CLS even on AMP. Next, dynamic components like amp-list or amp-bind that load content after the first render — if the area is not properly reserved, layout shift is guaranteed. Finally, custom web fonts poorly preloaded that cause visible FOIT or FOUT.

Does this rule apply to all AMP environments?

Mueller makes no distinction between self-hosted AMP and AMP served from Google Cache. Both must meet the same CWV thresholds. This is an important point because some believed that AMP cache, with its optimized CDN distribution, might benefit from more lenient treatment.

In reality, the cache helps significantly — nearly zero latency, pre-established connections — but does not compensate for poorly structured code. An AMP page that takes 8 seconds for LCP locally might take 4 seconds from the cache, but will still fall short of the threshold.

• AMP pages receive no special treatment for Core Web Vitals — same thresholds as standard HTML
• By default, AMP generally meets the criteria due to the technical constraints of the framework
• Main points of attention: programmatic ads, dynamic components, custom web fonts
• AMP cache improves performance but does not exempt from having clean code on the editor side
• A CWV audit remains essential even on AMP, especially in a real production environment

Is this position consistent with real-world observations?

Mueller's statement aligns perfectly with what we observe in production. AMP is not magical — it’s just a technical framework that eliminates 90% of common errors. The remaining 10% depend on the implementation and can be enough to derail metrics.

I have audited news sites where 80% of AMP pages were CWV compliant, but the remaining 20% — often sponsored articles with lots of ads or enriched content like interactive quizzes — significantly exceeded the thresholds. Google indeed makes no distinction: if LCP is at 3.2s, the page is classified as “needs improvement” even if it’s technically AMP.

What nuances should we consider regarding ease of compliance?

Mueller states that “by default AMP pages are generally fast enough to meet” the thresholds. This is true, but this wording masks a more complex reality. A basic AMP page — text, images, simple structure — will comply effortlessly. But as soon as you add customization, dynamic content, or aggressive monetization, the situation complicates.

What should you prioritize auditing on your AMP pages?

Your first reflex should be to extract the real CWV data from the Search Console, filtered by AMP URLs if you have a dual implementation. Lab tools (Lighthouse, PageSpeed Insights) provide a preliminary indication, but the real-world metrics from CrUX are what Google actually uses for ranking.

Focus on three risk areas. First, ad slots — test with and without to quantify their actual impact on CLS and LCP. Next, the dynamic components: everything that loads after the first render must have a fixed reserved space to avoid layout shifts. Finally, custom fonts: use font-display: swap and preload critical variants with <link rel="preload">.

How do you fix CWV issues specific to AMP?

For LCP, the classic culprit is an unoptimized hero image. Even though AMP handles lazy-loading, it doesn’t compress files for you. Use an image CDN with automatic compression (WebP/AVIF) and adaptive sizing. On mobile, a 1200px image loaded in full width while the viewport is 375px will kill LCP.

For CLS, the trick is to define explicit dimensions for all elements that can change size: amp-ad, amp-img, amp-iframe. If you’re using amp-list for dynamic content, set a minimum height with a skeleton loader. And test in real conditions — often, it’s the ad that doesn’t load in dev but blows up CLS in production.

When should you consider abandoning AMP?

If you maintain AMP solely for performance and your AMP pages do not meet CWV thresholds, the question is worth considering. Let’s be honest: maintaining two versions of the site incurs a cost — development, testing, editorial synchronization.

Do the simple calculation. How much organic traffic actually comes to the AMP URLs? If it’s less than 15% and the metrics are no better than the HTML version, you are investing resources for no gain. In this case, it’s better to focus efforts on a single hyper-optimized version. These optimizations may be complex to orchestrate alone — analyzing CrUX data, technical prioritization, cross-device validation. A specialized SEO agency in web performance can help you objectify decisions and implement fixes methodically.

• Extract real CWV data (Search Console + CrUX) filtered by AMP URLs
• Specifically audit ad slots and quantify their CLS/LCP impact
• Check that all dynamic components (amp-list, amp-bind) have reserved dimensions
• Optimize hero images: WebP/AVIF compression + mobile adaptive sizing
• Configure font-display: swap and preload critical fonts
• Compare AMP vs standard HTML performance on a representative sample of pages