Accelerated Mobile Pages (AMP): Dead or Evolved?

Remember when AMP arrived in 2015 promising to save us from sluggish mobile pages? Fast forward to 2025, and the question everyone keeps asking is whether the framework is gathering dust in a tech graveyard or whether it has simply become something different. The answer isn’t as simple as “dead” or “alive,” so let’s work out what’s actually happening with AMP.

You’ll learn where AMP stands in web development today, why Google’s priorities shifted after 2021, and whether implementing AMP still makes sense for your projects. We’ll look at the technical guts of the framework, examine real performance data, and see what publishers are doing with their AMP implementations. Just the facts you need to make good decisions.

AMP’s current market position

The AMP story isn’t about death. It’s about transformation. Think of it like your favourite band from the 2000s: still around, but with a changed sound, a few missing members, and a completely different fanbase. AMP has gone through something similar, and understanding that shift matters for anyone working in web development or digital publishing.

When AMP launched as an open-source HTML framework, it positioned itself as the antidote to bloated mobile web experiences. The promise was simple: strip out the junk, cache aggressively, and deliver fast pages. Publishers signed up because Google dangled a carrot, namely preferential treatment in search results, especially the coveted Top Stories carousel.

But here’s where things get interesting. The framework that once felt mandatory has become optional. That shift tells us a lot about where AMP sits in the market now.

Google’s shifting priorities after 2021

May 2021 was the turning point. Google announced that AMP would no longer be required for inclusion in Top Stories. Let that sink in. The main incentive for many publishers to adopt AMP, preferential search placement, vanished overnight.

Why did Google make this move? The company said it was about fairness and user experience. But Google was also responding to criticism. Web developers and publishers had complained loudly that AMP felt like a walled garden, a way for Google to control content distribution and keep users inside Google’s ecosystem.

The shift to Core Web Vitals as the primary ranking factor changed everything. Instead of prescribing a specific framework, Google started measuring actual performance. It was a smart move. It levelled the playing field and pushed developers to focus on genuine performance rather than just checking the AMP box.

My experience with publishers during this transition was interesting. Some breathed a sigh of relief and started planning their exit from AMP immediately. Others, surprisingly, stuck with it. The framework had become part of their infrastructure, and they were seeing benefits beyond search rankings.

Core Web Vitals integration

Core Web Vitals changed the game entirely. These three metrics, Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS), became the new standard for measuring page experience. And here’s the catch: you don’t need AMP to ace them.

LCP measures loading performance and should occur within 2.5 seconds of when the page first starts loading. FID gauges interactivity, with a good score being less than 100 milliseconds. CLS tracks visual stability, and pages should stay under 0.1. AMP pages usually hit these marks by default, but so can well-optimised standard HTML pages.

The question became: why maintain two versions of your content, standard and AMP, when you could build one really good version? For many sites, the answer was “exactly, why would we?”

But AMP still has advantages in certain cases, and this part matters. The framework’s restrictions make it harder to wreck performance. It’s like training wheels: maybe you don’t need them, but they stop you falling off the bike while you’re learning.

Adoption rates across industries

Let’s talk numbers. Adoption varies wildly by industry, and those patterns say a lot about where AMP still holds value.

News publishers are still the most committed to AMP, and it makes sense. They invested heavily in the infrastructure, and their content model, text-heavy articles with images, fits AMP’s constraints perfectly. The framework still gives them what they need: fast-loading pages that work reliably across devices.

E-commerce sites, though? They’re heading for the exits. The limits on JavaScript and custom functionality make it nearly impossible to build the rich, interactive experiences that drive conversions. You can’t easily implement sophisticated product configurators, dynamic pricing displays, or complex checkout flows within AMP’s restrictions.

Healthcare is an interesting case. Health insurers and medical content providers still see value in AMP because their audience is heavily mobile-dependent. When someone searches for health information on their phone, speed and reliability matter more than fancy features.

Publisher migration patterns

The migration patterns tell a compelling story. Publishers aren’t just flipping a switch and dropping AMP overnight. The process is more calculated than that.

Three distinct patterns have emerged. First, there’s the gradual sunset. Publishers keep their AMP pages but stop investing in new features or improvements, letting the framework fade away as they build better standard HTML pages. This is the most common approach among large news organisations.

Second, the hybrid strategy. These publishers keep AMP for specific content types, usually news articles and blog posts, while using standard HTML for everything else. It’s pragmatic. Why fix what isn’t broken?

Third, the complete exit. Some publishers ripped off the band-aid and migrated everything at once. This works best for smaller sites or those with technical debt in their AMP implementation. They often see a temporary dip in mobile traffic, followed by recovery as their improved standard pages gain traction.

What’s interesting is the role content management systems play in these decisions. WordPress sites can maintain AMP easily through plugins, so keeping it costs little. Custom-built publishing platforms face higher maintenance costs, which makes exiting more attractive.

The data shows that publishers who properly optimised their standard pages saw minimal traffic loss after dropping AMP. Those who didn’t often struggled. The lesson is clear: AMP was never a substitute for good web development.

Technical architecture and performance

Let’s get into the technical weeds, because this is where the real story lives. AMP’s architecture is both its greatest strength and its biggest limitation. That tension explains why the framework has evolved the way it has.

AMP is a restricted subset of HTML with custom components and mandatory validation. Think of it as HTML with guardrails. You can’t just throw any JavaScript onto the page. You can’t load stylesheets however you want. These restrictions are intentional, and they’re what enable AMP’s performance guarantees.

The framework enforces a few key principles: asynchronous loading of all resources, no render-blocking JavaScript, size-bound CSS (maximum 75KB), and predefined layouts for media elements. These rules remove the most common causes of slow page loads. They also remove flexibility.

AMP component library evolution

The AMP component library has grown a lot since launch. The official AMP documentation now includes over 100 components covering everything from basic layout to complex interactive features. But more components don’t necessarily mean more adoption.

The original components, amp-img, amp-video, amp-carousel, remain the workhorses. These handle 90% of what publishers need. The newer, more specialised components see far less use. It’s classic 80/20 stuff.

Recent additions have focused on e-commerce and interactivity. Components like amp-bind for dynamic content updates and amp-list for dynamic data fetching try to answer the “AMP is too limited” complaint. They work, sort of. But they feel like band-aids on a framework built for a different purpose.

The component library’s growth shows a real tension. AMP wants to be both simple and feature-rich, but those goals often conflict. Every new component adds complexity, which chips away at the “just works” promise that made AMP attractive in the first place.

My experience implementing advanced AMP components has been mixed. They solve specific problems and introduce new ones. Debugging gets harder. The mental model gets more complex. You start wondering if you’d be better off just building a proper web app.

Caching infrastructure and CDN

Here’s where AMP still shines: the caching infrastructure. When you serve an AMP page through Google’s cache, it’s stored on servers around the world, usually at Google’s edge locations. The result is very fast load times from anywhere.

The AMP Cache does more than store your pages. It validates them, optimises images automatically, and pre-renders content. This infrastructure is expensive to build and maintain. It’s one reason some publishers stay with AMP: they’re essentially getting enterprise-grade CDN services for free.

But there’s a catch. Google controls this cache. Google decides what gets cached, how long it stays cached, and when it gets updated. For some publishers, that lack of control is a dealbreaker. For others, it’s an acceptable trade-off for the performance.

The caching setup also creates analytics headaches. When users view your content from the AMP Cache, tracking gets more complex. You’re not seeing direct traffic to your domain, and attribution gets messy. These aren’t impossible problems, but they’re friction points that make some organisations uncomfortable.

Other CDN providers have entered the space with AMP caching services. Cloudflare, Fastly, and others now support AMP, reducing dependence on Google. This is healthy for the ecosystem but hasn’t changed adoption patterns much.

Performance benchmarks versus standard HTML

Let’s talk benchmarks, because this is where the rubber meets the road. How much faster is AMP, really? It depends on what you’re comparing it to.

Compared to the average website? AMP is dramatically faster. Studies show AMP pages usually load in under 1 second, while standard mobile pages average 3-4 seconds. That’s a huge difference. But the comparison isn’t fair. You’re comparing a restricted, optimised framework against the wild west of typical web development.

Compare AMP to a well-optimised standard HTML page, and the gap narrows a lot. A properly built page with optimised images, minimal JavaScript, and good caching can match or even beat AMP performance. The difference is that AMP makes it hard to mess up, while standard HTML gives you enough rope to hang yourself.

These numbers are telling. AMP’s advantage is clearest in Time to Interactive and page size. The framework’s restrictions on JavaScript and external resources keep pages lean. But optimised HTML can get close, especially with modern techniques like code splitting and lazy loading.

The question isn’t “Is AMP faster?” but “Is AMP worth the trade-offs for that performance gain?” For a news article, probably yes. For an e-commerce product page with complex functionality, probably no.

Benchmarks also vary by geography. AMP’s advantages are clearest in regions with slower mobile networks. In areas with fast 4G or 5G, the gap between AMP and optimised HTML shrinks. So as global mobile infrastructure improves, AMP’s performance advantages will matter less.

The real-world implementation reality

Theory is nice, but what happens when you actually run AMP in production? Let’s talk about the messy reality that never makes it into the marketing materials.

The first challenge is maintaining two codebases. Unless you’re building an AMP-first site (rare these days), you’re maintaining separate versions of your content. This doubles your testing burden, adds deployment complexity, and creates room for inconsistencies between your AMP and standard pages.

Content management gets trickier too. Writers and editors need to know what works in AMP and what doesn’t. That fancy interactive chart your team built? Doesn’t work in AMP. The custom form with conditional logic? Nope. You end up with feature parity issues where your AMP pages give a degraded experience compared to your standard pages.

Then there’s the validation headache. AMP pages must pass strict validation to be eligible for caching. One small error, a misplaced tag, an oversized stylesheet, and your page is invalid. The validation errors can be cryptic, and debugging them takes time. It’s like having a very picky code reviewer who never sleeps.

Development workflow challenges

Fitting AMP into your development workflow takes thought. You can’t just bolt it on as an afterthought. The AMP implementations that work treat it as a first-class concern from the start of the design process.

The best approach I’ve seen builds AMP-compatible components from the ground up. Instead of building a feature and then trying to make it work in AMP, you design with AMP’s constraints in mind. Your standard pages might be slightly less feature-rich, but your AMP pages aren’t a compromised version of the “real” site.

Testing gets complicated. You need to test both versions of your site across different devices and browsers. You need to verify that your AMP pages validate correctly. You need to make sure analytics tracking works in both contexts. It’s more work, plain and simple.

Version control strategies matter too. Some teams keep separate branches for AMP and standard versions. Others use templating systems that generate both versions from a single source. Neither approach is perfect: both trade off complexity against maintainability.

SEO and discovery implications

Let’s address the obvious question: does AMP still help with SEO? The short answer is “sort of, but not like it used to.”

AMP no longer gives a direct ranking boost. Google has said so plainly since the Core Web Vitals update. But here’s the nuance: AMP pages often perform better on Core Web Vitals metrics, which do affect rankings. So there’s an indirect benefit.

The Top Stories carousel, once AMP-only, now accepts any page that meets performance standards. That levelled the playing field but also removed AMP’s biggest carrot. Publishers who invested heavily in AMP for that placement found themselves wondering whether it was worth continuing.

Discovery mechanisms have changed. Google’s Discover feed, which serves personalised content to mobile users, doesn’t require AMP but favours fast-loading pages. AMP pages often do well here, but so do optimised standard pages.

One place AMP still matters is search result presentation. AMP pages can appear with a lightning bolt icon (though Google has played this down), and they usually load almost instantly when users tap search results. That can improve click-through rates and reduce bounce rates, which indirectly helps SEO.

Analytics and tracking considerations

Analytics in AMP land can feel like solving a puzzle with missing pieces. The framework’s restrictions on JavaScript affect how you track user behaviour, and the caching setup adds another layer of complexity.

The amp-analytics component handles most tracking needs, supporting major platforms like Google Analytics, Adobe Analytics, and others. It works, but with limits. Custom event tracking is more cumbersome. Real-time analytics get trickier when pages are served from cache.

Attribution gets messy. When users view your AMP page from Google’s cache, the referrer information changes. You might see traffic attributed to Google’s AMP cache rather than the actual source. That affects campaign tracking and makes it harder to understand your traffic sources accurately.

A/B testing brings its own problems. Traditional JavaScript-based testing tools don’t work in AMP. You need AMP-compatible solutions or server-side testing. That limits your options and can make experimentation slower and more expensive.

My recommendation? If analytics and experimentation matter to your business (and they should), factor in these limits when you decide whether to keep AMP. The performance benefits might not outweigh the analytics blind spots.

Alternative approaches and emerging patterns

So if AMP isn’t the silver bullet it once seemed, what are the alternatives? The web development community hasn’t been idle. Several approaches deliver similar performance without AMP’s restrictions.

Progressive Web Apps (PWAs) are one path. They use service workers for caching, offer offline functionality, and can deliver app-like experiences. PWAs don’t need a separate codebase; they’re enhancement layers on top of your existing site. Done right, their performance can match or beat AMP.

Static site generation has gained ground. Tools like Next.js, Gatsby, and Eleventy pre-render pages at build time, cutting out server processing delays. Combined with a good CDN, static sites can load as fast as AMP pages while giving you complete flexibility.

Edge computing is changing things too. Services like Cloudflare Workers and Fastly Compute@Edge let you run code at the network edge, close to users. That enables dynamic personalisation without sacrificing performance. It’s AMP’s speed without AMP’s restrictions.

Modern performance optimisation techniques

The performance toolkit has grown a lot since AMP launched. Modern browsers support features that make fast pages easier to build without frameworks.

Resource hints, like preconnect, prefetch, and preload, tell browsers what to load early. The loading="lazy" attribute on images provides native lazy loading without JavaScript. The async and defer attributes control script execution timing. These are built into the platform now.

Image formats have improved. WebP compresses better than JPEG. AVIF promises even better results. Modern browsers support responsive images through srcset and picture elements, serving appropriately sized images based on device capabilities.

CSS has become more powerful. Grid and Flexbox remove the need for heavy layout frameworks. CSS custom properties enable theming without JavaScript. Container queries (finally!) allow responsive design at the component level. You can build sophisticated layouts with minimal code.

JavaScript bundling has matured too. Code splitting means users only download what they need. Tree shaking removes unused code. Dynamic imports load functionality on demand. Applied well, these keep JavaScript payloads small and execution fast.

Framework-agnostic performance standards

The shift from prescriptive frameworks like AMP to performance standards like Core Web Vitals shows web development maturing. Instead of “use this framework,” the message now is “meet these metrics.”

This has real advantages. It’s technology-agnostic: you can use React, Vue, vanilla JavaScript, or no JavaScript at all. It focuses on outcomes rather than methods. It encourages innovation rather than conformity.

It also puts more on developers. You can’t just implement AMP and call it done. You need to understand performance fundamentals, measure continuously, and optimise as you go. Not every team has those skills or resources.

This is where services like Jasmine Web Directory become useful. They curate web resources and help businesses find quality development partners who understand modern performance optimisation. It’s about connecting people who need help with people who can provide it.

The role of content delivery networks

CDNs have become more sophisticated, with features that blur the line between infrastructure and application logic. Modern CDNs don’t just cache static content; they transform it, optimise it, and personalise it.

Image optimisation at the edge is standard now. CDNs can automatically convert images to optimal formats, resize them for different devices, and compress them intelligently. That removes one of AMP’s key advantages: automatic image optimisation.

HTML minification, CSS inlining, and JavaScript optimisation can happen at the CDN level. Some CDNs even support edge-side includes (ESI) for dynamic content assembly. You get performance benefits similar to AMP without changing your workflow.

These services have dropped in cost significantly. What once required enterprise budgets is now within reach of smaller organisations. This democratisation of performance infrastructure reduces the appeal of framework-based solutions like AMP.

Industry-specific considerations and use cases

Not every industry relates to AMP the same way. The value proposition varies a lot depending on your content type, audience, and business model. Let’s break it down by sector.

News and media organisations face unique pressures. They publish high volumes of content, need it to load instantly, and monetise through advertising. AMP’s restrictions on ads have always been a difficulty, but the framework does keep ads from completely destroying page performance. Many news sites found a middle ground: AMP for article pages, standard HTML for the homepage and section fronts.

E-commerce sites, as I mentioned, struggle with AMP. The limitations make it hard to build the rich product experiences that drive conversions. Product configurators, size guides, 360-degree views: these don’t translate well to AMP. Most e-commerce sites have abandoned or never adopted AMP, focusing instead on PWA approaches that offer better functionality.

Healthcare providers are an interesting case study. Mobile usage in healthcare searches is exceptionally high; people often search for symptoms, treatments, and provider information on their phones. The audience skews toward urgency; they want information fast. That makes AMP’s performance benefits particularly valuable.

Content publishers and media

Publishers invested heavily in AMP, and many still see value despite Google’s policy changes. The reasons are partly technical and partly strategic.

Technically, news articles fit AMP’s constraints well. They’re mostly text and images with minimal interactivity, so the framework’s limits don’t hurt the user experience much. In fact, by forcing a simpler design, AMP often improves readability on mobile.

Strategically, publishers like that AMP gives a consistent, reliable experience. With a fragmented mix of devices, browsers, and network conditions, knowing your content will load quickly everywhere has value. It’s one less thing to worry about.

Advertising complicates things. AMP supports ads through amp-ad components, but with restrictions. Ad networks had to build AMP-compatible versions of their ad units. Some did, some didn’t. Publishers using AMP often see lower ad revenue per page than on standard pages, though faster load times can bring more page views and offset the difference.

Healthcare and medical content

Healthcare makes a strong case for continued AMP use. The sector has traits that line up well with the framework’s strengths.

First, the audience is mobile-heavy and often in urgent need of information. Someone experiencing symptoms won’t wait for a slow-loading page. They’ll hit the back button and try the next result. AMP’s instant loading addresses that directly.

Second, healthcare content is usually informational rather than transactional. You’re not selling products or building complex user flows. You’re providing information: symptoms, treatments, provider details. That content type fits AMP’s restrictions perfectly.

Third, trust and authority matter enormously in healthcare. Fast-loading, professionally presented content signals credibility. AMP’s clean, consistent presentation conveys professionalism and reliability.

Healthcare organisations also face regulatory requirements around accessibility and privacy. AMP’s standardised components make accessibility compliance easier to ensure. And the framework’s restrictions on third-party scripts can help with privacy compliance by limiting data collection.

Small business and local services

Small businesses often ask whether they should implement AMP. It usually comes down to their technical resources and content strategy.

For a local restaurant or service business with a simple website, AMP might be overkill. If your site is basically a digital business card, with contact info, hours, a menu, and a few photos, you can get excellent performance with basic HTML optimisation. AMP adds complexity without proportional benefits.

But for small businesses that publish regular content, a plumber writing DIY tips, a dentist publishing oral health articles, a real estate agent sharing market updates, AMP can make sense. These businesses often lack in-house technical knowledge, and AMP’s “it just works” nature means they can publish without worrying about performance optimisation.

WordPress makes AMP especially accessible for small businesses. The official AMP plugin handles the technical side automatically. You write your content normally, and the plugin generates AMP versions. This low-friction approach has kept AMP alive in the small business segment even as larger organisations move away.

Future directions

So where does AMP go from here? The framework has moved from a must-have to a nice-to-have, but that doesn’t mean it’s disappearing. Its future just looks different from its past.

The AMP Project (now under OpenJS Foundation governance) has shifted focus from “AMP as a distinct framework” to “AMP as a collection of web components.” It’s clever positioning. Instead of requiring buy-in to an entire ecosystem, they offer individual components developers can use a la carte.

This componentisation might give AMP a second life. Developers who wouldn’t adopt the full framework might use specific AMP components in their standard HTML pages. An amp-carousel here, an amp-video there. It’s a more sustainable model than the old all-or-nothing approach.

The caching infrastructure will likely persist even if the framework itself fades. Google has invested heavily in it, and it provides value beyond AMP. Don’t be surprised if Google extends cache benefits to non-AMP pages that meet certain performance criteria. It has already moved this way with signed exchanges and other technologies.

Performance standards will keep tightening. Core Web Vitals are just the beginning. As mobile networks improve and user expectations rise, the bar for “good enough” keeps moving up. That creates ongoing pressure for performance optimisation, which indirectly helps frameworks like AMP that bake performance in from the start.

The question isn’t whether AMP survives, but whether its core insight lasts. The idea that you can get better performance through constraints, that less flexibility can mean more speed, still holds. Whether that shows up as AMP or as something else is almost beside the point.

Looking ahead, expect more framework-agnostic performance solutions. Technologies like HTTP/3, with its improved multiplexing and reduced latency, will make fast pages easier to build without specialised frameworks. Browser improvements will keep adding better built-in performance features.

The web is moving toward a model where performance is a property of good development practices, not a feature of specific frameworks. That’s healthier for the ecosystem. It rewards competition and innovation instead of lock-in to particular technologies.

For developers and businesses deciding today, the takeaway is clear: focus on performance outcomes, not specific technologies. Whether you achieve them with AMP, PWAs, static site generation, or careful optimisation of standard HTML matters less than actually achieving them. Measure what counts, load times, interactivity, visual stability, and optimise from there.

AMP isn’t dead. It has become something more modest and more sustainable than its original form. The framework that promised to save the mobile web is now one tool among many for building fast websites. That’s not failure, it’s maturity. The web is better for AMP’s existence, even if fewer sites use it today than at its peak.

The real winners are users, who get faster-loading pages no matter which technology delivers them. And that, in the end, is what all of this, the frameworks, the standards, the debates, should be about.