Is AMP still relevant for boosting your page speed?

Is AMP still addressing a real need in SEO?

Launched by Google, AMP (Accelerated Mobile Pages) aimed to standardize the creation of ultra-fast mobile pages. The framework enforces strict HTML, drastically limits JavaScript, and optimizes resource loading.

The promise was clear: reduce loading times to improve user engagement. News sites and e-commerce businesses widely adopted this technology when it provided access to the Top Stories carousel in mobile search results.

Why does Google keep this recommendation despite changes?

Google continues to mention AMP because the framework technically ensures high performance. The Google AMP cache preloads pages, offering instantaneous navigation between search results.

Yet, the real reason lies elsewhere. Since the introduction of Core Web Vitals as a ranking factor, any site can achieve comparable performance without AMP. Google cannot bluntly say that its technology has become secondary.

What does this strategic choice mentioned by Google actually mean?

This cautious wording masks a technical reality. Implementing AMP requires significant development resources: double templating, maintaining two versions of the site, and constraints on JavaScript functionalities.

The framework suits editorial sites with simple text content. For complex sites with rich interactions, advanced forms, or sophisticated user journeys, AMP becomes more of a hindrance than an accelerator.

• AMP is no longer a prerequisite to appear in mobile rich results since the Page Experience update.
• Core Web Vitals allow achieving the same performance objectives without AMP's technical constraints.
• The adoption rate of AMP is declining among major publishers returning to optimized native solutions.
• Google hides AMP by default and preloads pages, which skews the actual performance perception on the user side.
• The maintenance of two versions of the site (AMP and standard) complicates content strategy and analytics tracking.

Does this statement reflect the reality on the ground?

Let’s be honest: AMP has lost its status as an indispensable standard. CrUX data shows that non-AMP sites regularly outperform AMP versions on Core Web Vitals metrics. The Washington Post, a pioneer in AMP, has abandoned the technology in favor of an optimized native stack.

Google maintains this recommendation for institutional consistency, but signals from the field indicate a paradigm shift. A/B tests conducted on news sites show higher engagement rates on optimized standard versions compared to strict AMP versions. [To be verified]: Google has not published any AMP case studies for several years, indicating a gradual disengagement.

What are the real hidden costs of implementing AMP?

The double templating represents the major technical cost. Every feature added to the main site must be duplicated and adapted to AMP constraints. Teams lose development time on this parallel maintenance.

From an analytics perspective, tracking becomes a nightmare. Sessions switch between domains (Google's AMP cache vs. origin site), fragmenting user journeys. Multivariate conversion tests become complex to implement. Some third-party marketing tools simply do not work in an AMP environment.

In what cases does AMP remain a strategic relevance?

For 100% editorial sites with text and image content, AMP remains a viable solution. High-volume news blogs without complex interactions can benefit from Google's cache and preloading infrastructure.

Emerging markets with limited mobile connectivity represent another valid use case. In these contexts, AMP's aggressive compression and preloading compensate for high network latencies. But even there, a well-optimized PWA offers a more flexible alternative.

Should you migrate to AMP or abandon it if already implemented?

New implementation: not recommended unless in very specific use cases. Focus your resources on the native optimization of Core Web Vitals. Modern frameworks (Next.js, Nuxt, SvelteKit) offer comparable performance with more flexibility.

If AMP is already in place and generates significant traffic, do not abruptly break what is working. First, measure: compare engagement metrics between AMP and standard versions. If the gap is minimal, plan for a gradual migration.

How can you optimize speed without resorting to AMP?

The modern strategy relies on three technical pillars. First pillar: lazy loading of images and iframes, with preloading of critical resources via resource hints. Second pillar: minification and Brotli compression of HTML, CSS, and JavaScript.

Third pillar: a high-performance CDN with intelligent edge caching. Solutions like Cloudflare or Fastly provide response times comparable to Google’s AMP cache. Pair this with inline critical CSS and deferred JavaScript, you reach Core Web Vitals thresholds without constraints.

What indicators should you track to validate your technological choice?

Track the Core Web Vitals in real conditions via Search Console and CrUX. LCP (Largest Contentful Paint) should remain under 2.5 seconds, FID (First Input Delay) under 100ms, CLS (Cumulative Layout Shift) under 0.1.

But don’t stop at technical metrics. Measure adjusted bounce rate, engagement time, and conversion rate by page type (AMP vs. standard). These business KPIs reveal the real impact on your goals. A perfect LCP that kills conversion is worthless.

• Audit your pages with PageSpeed Insights and compare AMP vs. optimized standard scores.
• Test user behavior using heatmaps (Hotjar, Clarity) on both versions.
• Measure the impact on advertising revenue if you monetize via display.
• Check the compatibility of your marketing tools (CRM, automation, A/B testing) with AMP.
• Evaluate the development cost of double templating maintenance over 12 months.
• Analyze conversion paths from Search Console: what percentage comes from AMP?