Is AMP Dead?

Back in 2016 I wrote about our experiences and observations working with AMP. That was around a year after it was first announced and it was far from a glowing recommendation for the web newcomer. Fast-forward 5 years and I can’t say my opinion has changed.

Being honest I’ve only had to work with AMP a couple of times over the last few years and found it awful to work with each time. Maybe if I’d have worked with it more my opinion might have softened as my understanding deepened, but when there are far more versatile alternatives AMP has felt frustratingly restrictive. When I did have to battle with AMP it was pretty-much because it was the only option; providing benefits that standard HTML just couldn’t.

Why use AMP anyway?

Whether these are seen as benefits or not will depend on who you speak to and the specific use-case, but beyond its original mission to deliver fast webpages there’s two things that characterise AMP:

• The Google Cache; alongside the ability to serve content from a Google URL
• Access to the Top Stories News Carousel on Google Search

For some time, only AMP pages have been able to appear in the Top Stories News Carousel and this has been a big driving force in pushing adoption of AMP as no news outlet could afford to put themselves at such a disadvantage of not qualifying for such a visible section of the SERPS.

But in May that’s changing. With the introduction of the Page Experience Update Google will be opening up the Carousel to sites built using other technologies that return a high experience score. Just where the cut-off will be remains to be seen.

But while that potentially leaves bloated websites stuck with AMP for the foreseeable future, it gives the opportunity for those capable of building fast and lightweight website to return to maintaining a single version of their website.

Was AMP ever good?

Without the lure of Top Stories, non-news websites have never seemingly bothered with AMP in large numbers. Less than 1% of all websites use the technology and the development community has never really gotten behind the technology.

Many articles outside of the AMP Project itself lament the fragmentation of a core web language and deride its strong affiliations with Google; a company with a history of questionable practices.

While there’s always been nobility in its original mission of delivering a faster web, for many it took the wrong approach in trying to rebuild the web from scratch using a closed system that ultimately restricted freedom of choice and expression. Look at any AMP site and you’ll likely see a pared-down version of its HTML counterpart with anything but the content and most basic styling choices dictated by the AMP components used.

While AMP has continued to add features and thus bloat, HTML has matured so that websites can be optimised more for speed through the use of new technologies and more thoughtful decision making. HTML sites were never slow to begin with, they only grew to be due to an over abundance of features, assets and a lack of attention when it came to optimisation.

What’s the future of AMP?

With more meaningful speed metrics including Google’s Core Web Vitals which has helped set a standard that is more easily communicated to decision makers there’s been a big push towards a faster web without the use of AMP.

While there are many bloated websites, with large JavaScript bundles, the opportunity remains to deliver faster websites than is even possible with AMP, if you choose to.

So back to this articles headline; is AMP dead? The short answer is no, but it’s not looking good. AMP has never really succeeded in becoming a popular method of building websites, but possibly it’s achieved its mission statement of making the web faster simply by existing as something to work against.

A lifeline?

Though fully-fledged AMP websites/pages look less likely, as the benefits of using AMP reduce, the AMP Project isn’t ready to give up just yet. Instead, it appears to be pivoting towards providing AMP components under the name Bento that can be used in non-AMP websites.

This may extend the life of AMP for some time and does offer an intriguing use for the technology where a developer can pick specific components when it makes sense within the greater scope of the project. For example, calling the AMP Youtube component may prove more performant than the default iframe embed and quicker than authoring a custom lazyloader.
Maybe the future of AMP is in providing a library of performant UI components?