Accelerated Mobile Pages (AMP) is an open-source HTML framework developed by Google to create stripped-down, fast-loading mobile web pages. While adoption has declined since its 2016 launch, understanding AMP remains relevant for evaluating mobile performance strategies and legacy implementations.
Accelerated Mobile Pages is a technical specification that creates a parallel, simplified version of your web pages designed exclusively for mobile consumption. The accelerated mobile pages definition centers on three core components: AMP HTML (a subset of standard HTML with mandatory restrictions), AMP JS (a JavaScript library that manages resource loading and rendering), and AMP Cache (Google's content delivery network that pre-renders and serves pages). When a user clicks an AMP link in Google Search results, they receive a cached version served directly from Google's infrastructure rather than your origin server. This architecture eliminates most render-blocking resources and enforces strict validation rules. The accelerated mobile pages meaning extends beyond simple speed—it represents a tradeoff between performance guarantees and design flexibility. AMP pages cannot run arbitrary JavaScript, must load all resources asynchronously, and follow size limits on CSS. Publishers implement AMP by creating duplicate content: a canonical page and an AMP variant linked through HTML tags. This dual-publishing approach is what distinguishes AMP from typical responsive design.
AMP achieves its performance by imposing hard constraints that eliminate common bottlenecks. All external resources must declare their dimensions upfront, preventing layout shifts as images and ads load. Custom JavaScript is prohibited entirely—only the AMP runtime library executes, and it prioritizes above-the-fold content rendering. Third-party scripts like analytics or ad networks run in sandboxed iframes with restricted capabilities. CSS must be inlined and capped at 50 kilobytes, forcing designers to eliminate unused styles. Google's AMP Cache pre-fetches and validates pages, then serves them from edge locations closest to users. The cache also rewrites image URLs to serve optimized formats and applies additional compression. When a browser requests an AMP page, the runtime calculates resource priority, delays non-critical elements, and uses techniques like font display swap to prevent text-rendering delays. These mechanisms are baked into the specification—publishers cannot opt out of constraints while claiming AMP compliance. Validation tools flag any non-conforming markup, and invalid pages lose cache eligibility.
Between 2016 and 2020, publishers rushed to implement AMP because Google prominently featured AMP pages in a dedicated Top Stories carousel with a lightning bolt icon. This visibility drove significant mobile traffic, particularly for news sites competing for breaking-story placement. Google also hinted that speed influenced rankings, and AMP became the easiest path to guaranteed fast load times without deep performance engineering. However, in May 2021, Google announced that AMP was no longer required for Top Stories and that any page meeting Core Web Vitals thresholds qualified. The lightning bolt badge disappeared. This policy shift removed AMP's primary distribution advantage. Simultaneously, publishers grew frustrated with limitations: difficulty running custom ad formats, challenges with paywalls and subscriptions, analytics discrepancies between AMP and canonical traffic, and user experience friction from URL discrepancies (Google's cache URLs versus publisher domains). Modern responsive frameworks and image optimization tools now deliver comparable speeds without forking content. Consequently, many publishers either never adopted AMP or have since deprecated their implementations in favor of optimizing their standard mobile pages.
Despite declining mainstream adoption, AMP retains specific applications. High-volume publishers with tens of thousands of articles benefit from Google's free global CDN—hosting and bandwidth costs decrease when Google serves cached versions. Email clients like Gmail and Yahoo render AMP emails (AMP4Email), enabling interactive elements like carousels, forms, and real-time content updates inside messages without external links. Some advertising networks prefer AMP's sandboxed environment because it prevents malicious ad code from affecting page performance or security. Publishers in regions with slower mobile networks sometimes maintain AMP for markets where every kilobyte matters and infrastructure lags behind North American or European standards. Large organizations with legacy AMP implementations continue to support them to avoid content migration costs, especially when AMP traffic still represents measurable volume. Additionally, certain content management systems with built-in AMP modules make it trivial to maintain—WordPress plugins auto-generate AMP versions, so the incremental effort approaches zero for simple blogs.
The most common error is treating AMP as a ranking manipulation tactic rather than a user experience decision. Google's algorithm does not reward AMP status—it rewards speed and usability, which AMP happens to enforce. Publishers who implement AMP expecting automatic ranking lifts misunderstand the framework's purpose. Another frequent mistake is incorrect canonical and amphtml linking: the AMP version must reference the canonical with rel=canonical, and the canonical must reference the AMP version with rel=amphtml. Broken bidirectional linking causes indexing confusion and duplicate content issues. Many sites also create AMP pages that strip critical content elements—navigation, related articles, comments—assuming simplicity equals better performance, but this damages engagement metrics and time-on-site signals. Failing to validate AMP markup before deployment is another pitfall; invalid pages simply do not get cached or displayed in AMP-specific features. Finally, publishers sometimes neglect to track AMP and canonical traffic separately in analytics, making it impossible to assess whether the implementation delivers value or just fragments reporting.
Core Web Vitals now represent Google's official performance benchmark: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. Sites can achieve passing scores through standard optimization—lazy loading images, code splitting, CDN usage, server-side rendering, and resource prioritization—without AMP's restrictions. Progressive Web Apps combine fast load times with offline capabilities and app-like interactions, offering richer functionality than AMP allows. Modern image formats like WebP and AVIF, combined with responsive images using srcset, deliver file size reductions comparable to AMP's image optimization. JavaScript frameworks now support incremental static regeneration and edge rendering, pushing pre-rendered HTML close to users without Google's cache. Tools like Lighthouse and PageSpeed Insights provide actionable guidance for improving Core Web Vitals scores. For publishers evaluating whether to maintain AMP, the decision hinges on whether AMP traffic justifies the dual-maintenance burden. If canonical pages already meet Core Web Vitals thresholds and AMP represents minimal traffic, deprecation often makes strategic sense. If AMP still drives meaningful volume or serves specific technical needs, keeping it requires ongoing validation and content parity enforcement.
No, AMP does not provide ranking advantages. Google discontinued AMP's preferential treatment for Top Stories in 2021 and evaluates all pages based on Core Web Vitals and relevance regardless of technology stack. AMP pages rank well only if they satisfy the same quality and performance signals that apply to non-AMP pages. Speed matters, but you can achieve competitive speed without AMP.
Custom JavaScript is prohibited on AMP pages—only the AMP runtime library executes. You can include AMP-specific components like amp-carousel or amp-bind for interactivity, but no arbitrary scripts. Custom CSS is allowed but must be inlined in the document head and cannot exceed 50 kilobytes. External stylesheets are not permitted.
When Google serves AMP pages from its cache, the URL displayed is typically a Google domain (google.com/amp/...) rather than your domain. This creates branding and attribution challenges. Some browsers and platforms now support signed exchanges, which allow cached AMP pages to display your original URL, but implementation requires additional technical setup.
If AMP represents less than five percent of mobile traffic and your canonical pages meet Core Web Vitals thresholds, deprecation is often the practical choice. You eliminate maintenance overhead and content duplication. Implement 301 redirects from AMP URLs to canonical versions, update internal links, and remove amphtml tags. Monitor traffic and rankings for any shifts during the transition period.
Responsive design adapts a single page layout to different screen sizes using CSS media queries and flexible grids, allowing full JavaScript and design flexibility. AMP creates a separate, stripped-down page version with mandatory restrictions on code and resources. Responsive sites can be slow if poorly optimized; AMP guarantees speed through enforcement. Responsive is one codebase; AMP requires maintaining two versions of your content.
No, AMP is not required for Google News, Discover, or Top Stories. Google evaluates pages based on content quality, E-E-A-T signals, and Core Web Vitals performance. Non-AMP pages that meet these criteria qualify for all mobile search features. AMP may still appear more frequently in certain contexts simply because it guarantees fast load times, but it is not a prerequisite.