Accelerated mobile pages – what are they and what do they mean for the web?

Remember the old days, when websites were simple?

Just a bit of text, maybe a few hyperlinks and a couple of images. No video. Minimal interactivity. No single page applications. Web pages really were just pages.

Well guess what?

The old Internet is back.

The Accelerated Mobile Pages (AMP) Project is an open source initiative supported by a number of big publishers and championed by Google.

It aims to deliver faster web pages to mobile users, and it’s doing it by going back to basics.

AMP is primarily aimed at news publishers, and there are echoes of Facebook’s Instant Articles, but anyone can build an AMP web page and it will work in virtually all modern browsers.

How web pages have grown – and why this is bad for visitors on mobiles

Modern web pages tend to be big and packed with features. Gone are the days when they were just about delivering information. Now we live in a world of dynamic content, animations, search-as-you-type and instant chat windows.

The trouble is that the bells and whistles come at a price: they’re making the web slow.

Sometimes, the inherent sluggishness of bloated websites is masked by faster broadband (although there’s a limit to how much this helps), content delivery networks (CDNs) or clever prerendering.

However, not all of us are blessed with decent broadband connections, and the fact that so many of us are now browsing the web on mobile devices (and networks) has thrown us back in time. The mask drops, and we’re exposed to what it really means to be browsing the web in 2016: connections to third parties timing out, low-spec phones struggling to render oversized images, and forms that can’t be completed, still less submitted, until a big JavaScript file has loaded and executed.

It’s a world away from where we want to be.

AMP is an attempt to strip away the unnecessary content and protect us from ourselves. Here are a few of the key features of AMP (if you’re interested in the technical detail, you can read the full documentation here), as well as a quick look at what it might mean for website owners.


AMP pages use an extended, customised version of HTML. Some elements have been removed, a few have been replaced and a number of new elements have been introduced. Several of these new elements help to make up for the limits to the scripting you can do on an AMP page. Images, for example, work slightly differently, and you need to use a special <amp-img> element instead of the <img> element. This allows images to be lazy-loaded (loaded only as and when they’re needed), giving priority to the images needed to start viewing the page. This means visitors don’t waste time and bandwidth loading images they’re never going to see.


An AMP page has to have all the styles (CSS) needed for the page embedded within it. In other words, you can’t reference external style sheets (except those needed to load custom fonts).

This overcomes an inherent weakness in how a typical web page is put together. For most web pages, a browser requests and retrieves an HTML file, then discovers a reference to an external style sheet. At this point, it has to make second request and retrieve the style sheet before it can start displaying any content on the screen.

All this takes time.

By embedding styles directly in the HTML, this second step is eliminated, and the page can start to display much faster.

Why aren’t we all doing this already?

You don’t need to be building an AMP web page to embed styles in your HTML. You can already do this on any web page. However, the disadvantage is that the embedded styles can’t be cached separately from the HTML. This is a problem because you will normally want visitors to be able to store styles in their browser cache for a long time (because styles don’t change very often). HTML, however, shouldn’t normally be cached for very long (if at all). In the case of AMP, the trade-off is more likely to be worth it, since mobile phones have smaller browser caches than their desktop counterparts. AMP also puts an upper limit on the amount of CSS you can include on a page.


The basic rule is that you can’t use your own JavaScript on AMP pages.

That doesn’t mean that AMP pages are JavaScript free. Quite the opposite, in fact: there is a JavaScript library that has to be included in every AMP page. We’ve already mentioned that JavaScript often has the effect of slowing web pages down. Well, AMP JavaScript is designed to make them faster. It’s also loaded asynchronously, so it doesn’t interfere with the display of the page while it loads.

If you want to get your own JavaScript on to an AMP page, you have to use an iframe (effectively, a web page within a web page). What you can’t do is try to get around the ‘no custom JavaScript’ rule by putting all your content in an iframe and calling it an AMP page. AMP iframes come with their own set of restrictions, the most notable of which is that they can’t be anywhere near the top of the page. In other words, you can more or less put what you want in your iframe – you just can’t make this the ‘main’ part of the page.

This puts some serious limitations on what you can do on an AMP page, but it doesn’t mean you can’t add some level of interactivity. For example, AMP’s Extended Components allow you to create lightboxes, embed social media posts or include analytics.

Even though AMP’s JavaScript is loaded asynchronously, the fact remains that virtually any AMP page will require JavaScript to work. On the face of it, this doesn’t sound great for performance. Even if a basic AMP page (text and styles) starts displaying pretty quickly, for luxuries like imagery, you have to wait for JavaScript to load and execute. Fortunately, AMP has another trick up its sleeve to help remove this potential bottleneck: prerendering.


Prerendering involves loading a web page in advance, so that when a visitor clicks through to it, they’ll already have everything they need. This can give the impression that AMP pages load more or less instantaneously.

If this sounds familiar, it might be because Google has for some time been using a different kind of prerendering to deliver ‘instant pages’ in search results (in fact, anyone can prerender a page by using rel=”prerender” in a link element on the referring page).

‘Traditional’ prerendering is often disabled on mobile by default: when bandwidth and CPU are limited, loading a lot of extra resources that might never be needed isn’t the best idea.

So what makes AMP prerendering different?

In AMP, only the above-the-fold portion of the page is prerendered. This, coupled with the fact that AMP pages tend to be fairly light anyway, should help mitigate any negative impact. Since the cost of AMP prerendering is fairly small, it should also be possible to prerender multiple AMP pages (many of which will share resources anyway).

Google AMP Cache

Google is helping publishers speed up load times still further by caching AMP pages on its servers, effectively giving them access to a free content delivery network (CDN). You don’t have to take advantage of this, but if you don’t already have access to a comparable network, it could be a good way to get your AMP pages in front of end users that much more quickly.

SEO benefits?

Google already uses page speed as a ranking signal, and although there’s no indication that it will favour AMP pages per se, it’s probably reasonable to assume that (other things being equal) it will prefer an AMP version of a page over a non-AMP version.

Google also includes a horizontally scrolling carousel of AMP pages (complete with preview) in the results page when you search for something on a mobile, in much the same way as it does for several other kinds of content, such as shopping results. A small AMP ‘lightning’ icon is shown underneath each result, and it may be that users will come to associate this with fast-loading pages and be more inclined to click through to any page that features it.


This raises some interesting questions.

As we’ve mentioned, AMP works best for news sites – it’s not designed for ecommerce. So, when you search for something likely to be in the news (e.g. ‘David Cameron’), the first thing you get is a set of AMP pages from leading newspapers and broadcasters. If you search for something generic, such as ‘shoes’, you don’t. Instead, you get retail pages, which aren’t in AMP format.

What happens when there’s an overlap?

For example, what about something like the latest games console at Christmas? It’s probably going to be in the news as well as in the shops. But which pages will come up first in Google? Should retailers look to build AMP pages whenever they’re likely to be competing with news publishers for search ranking?

Why put up with the extra maintenance?

While AMP offers a number of benefits, it introduces a headache for site owners: suddenly, they have two sets of pages to maintain. This also seems to conflict with Google’s preference for responsive design – one URL with one design that reflows to suit the end user’s viewport. Now a significant number of sites will have separate, dedicated mobile pages.

Fortunately, there are now one or two solutions, such as the AMP PHP Library, that should help make the process run more smoothly.

It might be that the different uses for the web – and the different ways we have to access it – mean that a one-size-fits-all solution is no longer fit for purpose. We might find that AMP is the just one of a number of different specifications for different kinds of web page. Ultimately, we could end up being able to access a much more versatile web via a browser, with less reliance on dedicated apps.

Do we really need AMP?

There’s nothing magic in AMP. Apart from access to Google’s AMP cache and prerendering from results pages, you could create a standard web page that has pretty much the same features and that performs just as well as an AMP page.

However, AMP offers two things. One is a set of incentives: Google will grant you access to its proxy cache and give your pages special treatment in search results.

The other is convenience. Yes, you could write your own version of AMP pages. But why would you? In one sense, AMP pages are stripped back versions of standard web pages. However, while much of the functionality we’ve taken for granted has been removed, some of it has been handed back to us, repackaged in such a way as to minimise its impact on performance. Some very clever people have given us a way to build simple web pages that work well on mobile. If you look at it this way, and as long as you’re creating the kind of content that AMP’s designed for, it’s hard to see a reason not to make the most of it.

2 thoughts on “Accelerated mobile pages – what are they and what do they mean for the web?

  1. “Thank you for the article.
    Can you please explain a bit more how to see AMP pages in action (if I’m located not in the US/UK)? I followed the 1-4 instructions, but what is step 5, what exactly should I search in Google to find an AMP article(s)?”

    • Web Performance Expert

      Thanks for commenting. Well, you could just search for something that’s likely to bring up some news pages – for example, a topical story or even just ‘breaking news’.

Leave a Reply

Your email address will not be published. Required fields are marked *