What Are AMP Pages and How Do I Use Them on My Site?

Amp pages are a type of page created using rules from the AMP system. AMP stands for the Accelerated Mobile Pages project, which is spearheaded by Google and a coalition of other entities attempting to make the web a better place for mobile users of all sorts.

The Fundamental Issue

AMP is a solution to a problem, and to understand its value, you need to understand the problem. Thankfully, it’s a very easy problem to grasp.

When you browse the web using a mobile device, like a smartphone, a tablet, a Kindle, or whatever new technology comes out later, you’re doing it on a small, underpowered device. Sure, smartphones today are more powerful than computers from two decades ago, but the internet is also a very different place. Computers from 20 years ago couldn’t render huge images, play music, stream video, or play Flash content any more than underpowered cell phones can today.

In the early days of the internet, a webpage might have half a dozen HTML tags and some plaintext content, probably a few hyperlinks, and not a lot else. The average website was a mere 14.1 kilobytes, which isn’t even enough for a website favicon these days. Compare that to today, where the average size of a website is closer to 2 megabytes. Keep in mind that this still includes a ton of plaintext sites drawing down the average. Something like YouTube is exponentially higher in size when you factor in streaming video.

Mobile devices are powerful enough to handle most of this, but they run into limitations. It’s not necessarily processing power holding them back; it’s communications bandwidth. Mobile carriers are always promoting their next new 4G5G6G7G8G whatever service, boosting speeds to what is still a fraction of many broadband desktop connections. Users can choose to connect via wifi, but even that has limitations. Combined with the smaller caches, smaller processors, and smaller amounts of RAM in smartphones and the like, and you have a significantly slower mobile experience.

The problem is this: a lot of the web is bloated. It’s fluffed up with needlessly large images, scripts that have trouble running or don’t run at all on mobile devices, live football streaming media, embedded content from a dozen other domains, and a whole lot more.

Google has been making large strides towards making the web a more mobile-friendly place. The advent of responsive design was not their doing, but the fact that responsive design is now a search ranking factor certainly has. Even so, a responsive design is not necessarily a fast design, and many websites are still bloated and slow, even when designed with mobile in mind. Not every developer has the same idea of what mobile can do, and some don’t push themselves hard enough to reach the limits of speed over functionality.

The AMP Solution

AMP is the newest version of a solution to this problem. The idea is to set forth a set of rules – in the form of a “subset of HTML” – that force the developers in question to work within certain constraints. The end goal is to create websites that render quickly and present content as close to instantly as possible, for web browsers using mobile devices and mobile connections.

Facebook created a pilot program very similar to AMP, called Facebook Instant Articles. FIA is designed to allow publishers to host their content on the Facebook infrastructure, which is very robust and designed to present content quickly. However, there are drawbacks, namely that the content is on Facebook and not on the website of the content creator.

AMP pages are websites designed from the ground up to load very quickly, on the host of the website owner, presenting their content for mobile users in the most ideal way.

AMP is also designed with integration in mind. Apps that can draw content from a page and present it within the app will be able to load it quickly via an AMP page rather than through a standard page, which cuts down on delays significantly.

On top of all of this, AMP is powered by Google, and Google has provided something called the AMP Cache. This is a cloud-based cache service that caters explicitly and exclusively to AMP pages, giving them an incredibly fast server infrastructure. If you have a fast coded page, the bottleneck becomes your web host. If you offload your web hosting to the Google cache, the bottleneck becomes the client’s web connection. As fast as that connection is, is as fast as the content appears.

What AMP Really Is

AMP is, as mentioned, a “subset of HTML.” What this means is that it’s a carefully chosen selection of valid HTML tags that can be used to create a page. Tags that put load on mobile devices, tags that enable bugs that can be detrimental to mobile devices, and tags that are deprecated and don’t render properly are all verboten.

This doesn’t mean your pages are limited to plaintext and basic HMTL. You can also use scripts, with a limited JavaScript library. This library includes the tags necessary to run most common ad programs, so you’re not left without ads. The same goes for Analytics, particularly Google Analytics, which Google obviously wants to include. Additionally, AMP provides guidelines for adding images and optimizing them, as well as other forms of media. For example, they support HTML5 video, but not Flash, partially because Flash has a checkered history with mobile devices and partially because it’s inefficient and a poor codec for video.

AMP pages will help your site in terms of SEO. All of the content is still on your site, it’s still associated with your URL, it’s just coded in a way that makes it prioritize speed over fluff. Google says they don’t promote AMP over regular pages, but it’s likely only a matter of time before they do. Besides, they already do implicitly; faster pages get preference over slower pages, and pages that are made for mobile get preference in mobile search. AMP covers both of these factors.

How to Implement AMP Pages

AMP pages are new pages for your site coded in a different way. That’s it. You can recreate your existing website using AMP code, but you may have to make some sacrifices. If your code includes scripts that require JavaScript code that isn’t supported, you will have to either re-code those scripts or learn to do without them.

Yes, this means you are either going to make a partially-AMP chimera site with some pages coded quickly and some with legacy code, or you’re going to have to go through an entire site redesign. This is why the first step towards implementing AMP is to talk to your developer. Seriously, this is not something you’re going to be able to do yourself unless you’re a practiced coder with a knack for interpreting GitHubs and experimenting with limited code.

While AMP is designed to work with all forms of content, it is best when used with mostly text content, such as blogs. Content that requires dynamic code, like social networks, will be stymied by the limitations. However, it’s not like Facebook is about to dig into AMP for their own code base; they have their own standards. Blogs can and should convert when possible, for a good, fast web base.

There’s nothing tricky about implementing AMP beyond the fact that it’s a code redesign. Simply talk to your developers about an AMP-standard website redesign, and they’ll walk you through the rest.

AMP’s Dirty Secret

A provocative title, but one that’s not necessarily off base. The Accelerated Mobile Pages Project is an interesting concept, and it’s certainly doing wonders to make certain sites faster, but in the six months since it was debuted, you can count the number of sites that use it on a couple of mutant hands. According to their site, only 47 North American sites use it, and while some of them are big names – the New York Times, Entreprenuer, CNN, Disney, eBay, Vox – that doesn’t herald widespread adoption or support.

AMP is not actually new code. It’s not a new coding language. It’s not in any way truly unique outside of its presentation. It would be as if Coca-Cola took Diet Coke and produced a brand new soda with an entirely new name not associated with Coke or Diet. It still has the same formula, the same taste, the same sugar restrictions, it’s just called something different.

This is what AMP is: basic HTML and JavaScript best practices, wrapped up in a pretty bow. It’s a selection of restrictions based on ideal circumstances, designed to force web developers to adhere to speed and mobile accessibility guidelines.

AMP itself does not offer anything unique. It brings nothing to the table. You do not get an incentive or a reward for switching to AMP, like you might switching from Allstate to Geico. If you have a site that performs well already, one that is fast-loading and accessible from mobile devices, you gain nothing in the change to AMP code.

In much the same way, using the Google AMP Cache gains you very little or nothing if you already have a high speed CDN or very good web hosting. One server is very much like another, despite any other fancy name; as long as it’s fast, it doesn’t matter who owns it.

AMP is there for two reasons. The first is as a set of rules for web developers to adhere to in order to make a fast site. Experienced and high quality web developers won’t need these guidelines, because they already know how to make a fast site. They already know what the best practices are. They know how to cater to mobile, in a possibly more robust way than AMP allows. However, any web developer that isn’t on the ball, or a developer that needs directing, can be forced to work inside the constraints of AMP and come out with a fast loading site.

The second reason is convenience. You don’t have to study web history, study HTML and CSS and JavaScript and XML and all the rest, study all sorts of industry best practices. You don’t have to filter through information from 2003 that may or may not even apply. You have rules and guidelines built in to the code you’re using, though it’s familiar as its basis is HTML. You can let the code restrictions do the heavy lifting, secure in your assumption that the code you produce will be fast when it’s done.

AMP does have the benefit of coming with free access to Google’s Cache CDN, and the fact that it’s free itself is certainly nice. You don’t need to buy an expensive framework and develop a website on top of it. However, again, if you already have a good CDN – or a site fast enough to not need one – you don’t get any benefit from switching to AMP.

AMP has a significant drawback, though, and that’s the framework itself. The fact that it is restricted in what it can do is by its very nature a hindrance to the flexibility and openness of the web. It’s certainly a worthy goal to make an effort to make sure mobile devices are capable of rendering anything on the web, but at the same time, the advancement of microtechnology is making that more and more true every year as well. We don’t have to dial back our code when we can push forward our hardware to meet it.

For this reason, I believe that AMP is forever going to be a niche coding style, and not a must-have for every blog or business out there. It’s not like responsive design, which is more and more essential to the broadly diverse nature of browsing devices. Rather, it’s a method savvy consultants can use as a buzzword to get behind-the-times websites to comply with modern web standards, without having to explain all of those modern web standards.