The Ultimate Guide to Converting a Web Page to AMP

Not all that long ago, Google announced that site speed was going to be a search ranking factor. After that, they announced that mobile friendliness was also a ranking factor, and likely a more important one. After all, an increasing number of users are browsing partially or entirely via mobile devices, so not having a mobile friendly page cuts out a bunch of potential traffic.

Now, these two things are combining. KISSMetrics has shown that 40% or more of your web visitors will abandon your site if it takes more than about three seconds to load. The longer it takes, the more traffic you lose.

While this has been common knowledge for websites for a long time, people don’t necessarily apply it to mobile browsing. Desktop sites are, by and large, quite fast for most normal we browsers. Sure, some people still have ultra-slow DSL or even dial-up connections, but those are the exception; the speed of the site is limited by their reception, not by your provision.

Mobile sites, however, tend to take longer to load. For one thing, cellular networks, even 4G or 5G or 7G or whatever branding we’re up to now, have limited throughput and slower download speeds. They don’t handle multi-server connections all that well either, meaning putting content and scripts on a CDN can exacerbate the problems of using multiple domains to serve content. Ads are a big factor as well; many mobile ad services don’t care about speed, and some sites – I’m looking at you, wikia networks – are often so laced with ads that getting to see the content you want to see within five minutes can be a chore. Scripts, too, are an issue, with mobile devices less able to cope with poorly coded scripts.

The solution to this whole problem is provided by Google, but it’s not necessarily the ideal solution to everyone.

The Solution

The solution is AMP, or Accelerated Mobile Pages. AMP, or the AMP Project as it’s known, is an initiative sponsored and promoted by Google and supported by other companies, including DoubleClick, OutBrain, Adobe, Quantcast, LinkedIn, Reddit, WordPress, Vimeo, and more. It’s an open source initiative aimed at standardizing fast, reactive code on websites.

For those of you who are older developers, who may have been around and active in the early days of the web, you might remember a time when HTML was the only thing a website had. Scripts were rare and minimal, content was served directly, formatting was handled by HTML commands like color=”blue”, and multimedia was a dream. Then there was a push to advance HTML and standardize some aspects of the web. This is how we gained things like CSS, to replace clunky HTML parameters. It’s how we evolved into standardized scripts, CSS3, HTML5, and other such modernizations and standards for the web.

You might also remember some “failed” initiatives. Google’s previous attempt to add another layer of standardization to the web was Schema.org, which works and is effective at what it does, but it’s not a tangible enough benefit for most sites to care.

AMP is simultaneously like and not like all of this. It’s a push to standardize the web in a new paradigm, but it has a great deal of value behind it. It’s a way to create or rebuild a website from the ground up so that it caters to mobile and, more importantly, is very fast at serving content. The idea is so that mobile users can be served content instantly or as close to instantly as possible, giving them a robust, user-friendly experience.

And, of course, it’s good for business. Not only do you avoid that drop-off of traffic, you also might be preparing yourself for the future. In December of last year, Google hinted that using AMP may eventually be a ranking factor, something they never did for Schema or any of the other code initiatives. That’s huge, and if it happens, it could pay off to revise your site sooner rather than later.

How AMP Works

AMP does not replace your existing website. Think of it in a similar way to how a mobile website worked before responsive design came along. A site on www.m.website.com was a completely different page as www.website.com, with the same content, stripped down for mobile users.

AMP works in a similar way, comprised of 2-3 components.

1. AMP HTML. This is a subset of HTML that you’re allowed to use. It restricts the use of commands and code that doesn’t work, works poorly, or works slowly on mobile devices. You can read all about it here. You are also limited to a streamlined version of CSS.
2. AMP JS. Where AMP HTML is a subset of HTML designed for fast mobile use, AMP JS is a subset of JavaScript that works the same way. It’s a specific JS library you can use to write your scripts. For example, it requires that content from an external source – like a CDN – be loaded asynchronously.
3. AMP CDN. This is a content delivery network and cache provided by Google, using their nigh-infinite computing resources. It caches AMP content and makes some automatic performance enhancements. You can put any or all AMP content on it, including the HTML file, any JS files, and all images. It’s an all-or-nothing thing for your AMP page, though, which is why it’s optional. If your web server is speedy enough, you don’t need to use Google’s AMP CDN at all if you don’t want.

Here’s an example in action. This article from The Guardian is a normal HTML page that, according to Pingdom, takes nearly 5 seconds to fully load, though a lot of that is loading ads and the embedded Twitter content. The time to actually load the content to visibility is much shorter. Now this link is the same article loaded through AMP. You can add /amp to the end of any Guardian URL to see the mobile version, by the way. Again according to Pingdom, the speed test for this post is 886 milliseconds. It has 53 requests and a page size of 482 kb, as opposed to the desktop version, which has 248 requests and a 2.3 mb page size. You can see an immediate difference.

One thing to note is that you can still serve ads on your AMP pages, you just have to use AMP-formatted ads through one of the AMP platforms. A lot of the major ad networks support AMP, to varying degrees, but if you have a custom ad solution, you will need to work with a developer to code it properly within AMP and get it added to the AMP supported list.

There are a few cons to using AMP. For one thing, you have to validate any AMP page before you can use it fully. You also have to special load custom fonts, declare the dimensions of images, and a few other coding quirks. Perhaps most importantly, though, you can’t use forms. No opt-ins allowed just yet, though I would anticipate Google adding an AMP-safe way to harvest information eventually.

Converting to AMP

First of all, if you’re not a developer, my advice is to contact a developer. AMP is complicated enough and restrictive enough that it will benefit you to find someone who is familiar with the system to get you up and running quickly, rather than poke around at it slowly on your own. It’s not quite like learning an entirely new coding language, but it’s close.

The simplest path to AMP-readiness is to make an entirely new version of your website, a sort of shadow copy, made to replicate your site in AMP. Your desktop page won’t change, but mobile users will be directed to the AMP version instead of the desktop or another mobile version. If you already use a responsive design, don’t worry; you can keep it as it is and layer the AMP version on top of it and there will be no conflict.

If you use WordPress, the absolute most simple way of implementing AMP is easy. All you have to do is download the official AMP WordPress plugin. Now, keep in mind that AMP is in active development. They push updates every Thursday, which means your plugin will be out of date very quickly. You will want to update the plugin on a regular basis, though you don’t necessarily need to do it every week.

Once the plugin is installed, you can test to see if your AMP pages work by adding /amp to the end of your URLs. Or, if you don’t have human-readable permalinks and use parameters instead, you can add ?amp=1 to the end to test and see.

You’re not quite done. You still have to validate your AMP pages, and to do that, you need to use the official validator. You can find the various options – command line, web interface, developer console, etc – here, as well as the documentation for using it and for fixing errors.

What if you’re not a WordPress user, but you are a developer? In that case, you’ve got your work cut out for you. A good place to start is the basic AMP tutorial, which will help you work your way through making an AMP-ready HTML page. It goes over the specifics of what HTML and CSS you can and can’t use, as well as the tricks for including images and media, and modifying the basic AMP templates. To the left of that page you will also see other guides, including how to use iframes, how to use third party content, and how to configure analytics for AMP pages. All of these are quite important.

If you want to use forms, you can opt in to the AMP developer channel here. You will need to toggle on amp-form. This will allow you to use the AMP form parameters on an experimental basis. Unfortunately, they won’t work for your users unless they too have opted in, and any document using experimental AMP features will not pass validation. It’s only a workaround for creating AMP-ready form pages for when the form feature leaves experimental development and enters the core project.

Should You Care About AMP?

The biggest question at the end of the day is whether or not you should care about or jump on to using AMP. Google is heavily pushing it, but they haven’t gone so far as to make it a core ranking signal, or even to create a Panda-like experimental secondary filter to test the outcomes. In other words, NOT using AMP won’t hurt you, but using it can help you.

Here are some guidelines to see if it’s something you should invest the time and, potentially, money, into implementing.

The primary question is whether or not you already have a fast-loading mobile version of your site in place. If you do – and by fast loading I mean under 2 seconds – you’re in the clear. You probably don’t need to care about AMP. Right now, AMP only benefits the search ranking of a site because it’s a way of speeding up a site and making it mobile ready, both of which are search factors on their own. Whether you do that with AMP or with your own custom code doesn’t matter, so long as mobile users can view it and it loads quickly for all users.

Next, are you the kind of person that loves to be on the cutting edge of new things at all times? Were you an early adopter of fancy HTML5 and CSS3 effects? Were you using video marketing and social media before anyone else in your niche? If so, by all means, dig into AMP. It’s probably not going to have an immediate beneficial effect, at least not if your site is already fast loading, but it prepares you for the day when Google decides AMP should be a ranking factor of its own.

Finally, do you care about mobile? There are certainly some sites, like B2B brands and sites thrown up for informational purposes rather than commercial purposes that don’t really care about mobile users. If you don’t and won’t ever care about mobile, go ahead and ignore AMP, or at least wait and see how it turns out.