Does AMP really ensure good Core Web Vitals?

Why does Google specify that AMP can fail Core Web Vitals?

John Mueller's statement debunks a persistent myth: AMP is not an automatic pass for performance criteria. Historically, AMP has been marketed as a miracle solution for speed — simplified HTML, restricted JavaScript, and limited inline CSS. Many SEOs have thus integrated AMP under the assumption that the Core Web Vitals would automatically be satisfactory.

However, Google reminds us of a technical reality: AMP imposes constraints but does not control everything. The size of images, third-party scripts allowed via amp-analytics or amp-ad, client-side rendering, poorly loaded web fonts — all these can degrade LCP, CLS, or FID. The framework mitigates issues, but it does not eliminate them completely.

What elements of an AMP page can degrade Core Web Vitals?

The main culprit often remains the Largest Contentful Paint (LCP). A poorly sized hero image or one served without modern optimization (WebP, AVIF) negatively impacts LCP even on AMP. The amp-img components apply lazy-loading by default, but if the main image is at the bottom of the loading cascade, LCP skyrockets.

The Cumulative Layout Shift (CLS) is also problematic: ads injected via amp-ad can shift content if placeholders are not sized correctly. Web fonts loaded via @font-face without font-display:swap cause FOIT (Flash Of Invisible Text), which deteriorates the experience. Finally, the First Input Delay (FID) can suffer if complex AMP components (carousels, videos) monopolize the main thread.

Does AMP still have value if Core Web Vitals are not guaranteed?

This is the tricky question. AMP imposes heavy architectural constraints — a double technical stack, separate maintenance, frustrating CSS/JS limitations. If the performance advantage is no longer automatic, the cost-benefit balance seriously tips.

In practice, AMP remains useful in specific contexts: news sites eligible for Top Stories (even if the AMP requirement has disappeared), e-commerce sites with simple catalogs, advertising landing pages where strict HTML control prevents issues. But for a classic editorial site or a SaaS, investing in a modern, well-optimized stack (Jamstack, edge rendering, image CDN) often yields better results without the constraints of AMP.

• AMP is not a magic shield: Core Web Vitals must be measured and optimized even on AMP pages.
• Common failure causes: large images, improperly sized ads, blocking web fonts, complex components.
• The cost/benefit trade-off: AMP imposes technical debt that is only justified if the performance gain or Top Stories eligibility compensates.
• The required on-the-ground test: use PageSpeed Insights and Search Console to check every AMP template, not just a sample.
• Modern alternatives: optimized frameworks (Astro, SvelteKit), edge rendering (Cloudflare Workers), image CDNs (Cloudinary, Imgix) can match or exceed AMP without the constraints.

Does this statement contradict the initial promise of AMP?

Yes and no. Google has never officially guaranteed that any AMP page would pass Core Web Vitals — but the initial marketing of the project clearly implied that performance would be assured by default. Presentations from 2016-2017 showcased impeccable Lighthouse scores and loading times under one second.

However, Core Web Vitals, introduced in 2020, have shifted the goalposts. LCP does not measure the same thing as First Contentful Paint or Speed Index. CLS penalizes behaviors that AMP does not natively block (missing placeholders for ads). The framework has aged, the criteria have evolved, and Google is adjusting the narrative accordingly. [To verify]: no public statistic from Google documents the CWV compliance rate of AMP vs non-AMP pages with equivalent data.

What are the practical limits of AMP against Core Web Vitals?

The architecture of AMP poses difficult constraints to navigate. The mandatory lazy-loading of images via amp-img improves initial weight, but sometimes delays LCP if the hero image is not prioritized. The amp-carousel or amp-lightbox components add validated JavaScript, but this JS remains JS — it can block the main thread.

The real problem is that AMP delegates a lot to third parties. Ad networks inject their own amp-ad components, often heavy and poorly sized. Analytics tools (Google Analytics via amp-analytics) add network requests. Google Fonts, even in AMP, require manual configuration (preconnect, font-display) to avoid worsening CLS.

In what cases is AMP still relevant despite these limitations?

AMP retains usefulness in specific niches. For news sites eligible for Top Stories, even though the AMP requirement has disappeared, the AMP version can serve as a quick fallback for mobile readers with slow connections. AMP pages are often cached on Google's CDNs, which speeds up TTFB (Time To First Byte) — a neglected but real advantage.

For advertising landing pages (Google Ads, Facebook Ads), AMP imposes a strict framework that prevents drift on the developer side (no rogue blocking scripts, no 2 MB CSS). This enforces useful discipline in contexts where marketing teams add tracking pixels without coordination. But outside these cases, the technical debt often outweighs the gain: maintaining two versions (AMP + canonical), synchronizing content, debugging specific AMP behaviors — all of this is costly.

How do you audit Core Web Vitals on existing AMP pages?

Start by identifying all indexed AMP URLs via the Search Console: Page Experience report, filter by page type. Export the complete list, not just a sample — CWV issues are often specific to certain templates (product pages, articles with video, ad landing pages).

Then, test each template with PageSpeed Insights in mobile mode, on the actual AMP URL (not the canonical). Record the field metrics (Field Data) from the Chrome User Experience Report, not just lab data. If Field Data is absent (insufficient traffic), lab data will provide an indication, but be aware: they do not capture actual ad behaviors (ads do not always load in the lab).

What priority optimizations should be applied to underperforming AMP pages?

To improve the LCP, start with hero images: switch to WebP or AVIF, size the srcset correctly, add fetchpriority="high" on the main image (AMP has supported this attribute since 2021). Use an image CDN that automatically generates modern formats and adaptive sizes (Cloudinary, Imgix). Ensure that the LCP image is not using lazy-loading — amp-img applies lazy by default unless you add the disable-inline-width attribute.

To reduce CLS, systematically reserve space for dynamic components: amp-ad should have explicit width/height attributes, and fonts should use font-display:swap in the inline CSS. If you are using amp-carousel, set a fixed height and avoid reflows when loading slides. Cookie or GDPR banners should appear in a fixed position without shifting existing content.

Should you abandon AMP if the optimizations are insufficient?

This is as much a business decision as a technical one. Evaluate the maintenance cost of the AMP stack (dual development, specific testing, debugging components) against the actual traffic served via AMP. If less than 10% of sessions go through AMP URLs and CWV remain in the red despite optimizations, the ROI is questionable.

In this case, migrating to a modern unified architecture (Jamstack with SSG/SSR, edge rendering, image CDN) simplifies the stack and often improves performance in a more sustainable way. Frameworks like Astro or SvelteKit generate nearly static HTML with minimal JS, resulting in excellent CWV without the AMP constraints. If you leave AMP, remember 301 redirects from old AMP URLs to canonical ones, and monitor Search Console for any drop in crawl or indexing.

• Audit all AMP templates via Search Console + PageSpeed Insights (Field Data priority).
• Optimize hero images: WebP/AVIF, adaptive srcset, fetchpriority="high", image CDN.
• Reserve space for dynamic components (amp-ad, amp-carousel) to avoid CLS.
• Configure web fonts with font-display:swap and preconnect to Google Fonts or similar.
• Test real ads in a staging environment to capture CLS/LCP behaviors.
• Assess the cost/benefit of AMP: if AMP traffic is marginal and CWV are poor, consider migrating to a modern unified stack.