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.
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.
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.
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.
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.