OPINION - Do we really need Google's Accelerated Mobile Pages (AMP)?

Google has just announced the Accelerated Mobile Pages Project (AMP), which "aims to dramatically improve the performance of the mobile web" or, alternatively, fragments the Internet by not fully supporting the very standards the web is built upon - depending on your point of view. As well as that announcement they have launched the AMP Project website (which I discuss in more detail below). So is it a good and necessary step forward or a massively step backwards?

Mobile web usage has over taken the desktop usage, at least in search. This does not necessarily mean that mobile has killed the desktop (studies have shown that actual desktop use has stagnated rather than started declining), but there is no doubting that mobile is massively important for any website.

In some ways developing for mobile is actually easier. Smartphones are relatively new compared to desktop computers and so the browsers on them are much more standards compliant, and there is often not as much need to code around legacy versions of Internet Explorer, like you have to on the desktop. In my experience users are also much more prepared to blame their mobiles when a browser is slow or doesn't load, rather than blaming the website. Additionally the way they are sold, often on 2 year contracts, encourages upgrades that desktop computers do not - so the average mobile will potentially continue to be fresher than desktop (though that argument is countered by the fact that many mobile operating systems depend on the carrier to upgrade, so are stuck on old versions until they upgrade, not to mention that outside the first world the picture is not as rosy).

However on the other side, developing for mobiles, is like developing for computers 10 years ago: screen sizes are small, input is difficult (mostly based on touchscreen with no keyboard), memory is limited, network latency is atrocious, network bandwidth (while it potentially can be better than broadband) plummets as soon as there is any congestion. Some of these restrictions simply cannot be fixed. Despite an increase in screen size and resolution as technology marches on, screen sizes are restricted by the very nature of the device and short of a new way of showing output (e.g. Google Glass, but that's not really taken off), this will always be a problem. Similarly, input methods are also limited by the physical size of the device and while mobiles have pushed forward other input methods like touch to the mainstream, it's still a challenge. CPU, memory and network bandwidth will only increase, but the biggest issue will be with the network latency - again due to the nature of the platform. HTTP/2 will help a lot with this, but there are physical limitations to the latency issues.

These restrictions are happening at the same time as trends show websites continuing to grow in size and complexity. So we have less resources, but increasing need of resources, on the primary platform of the future of the web. I'm sure we've all suffered from staring at a blank mobile web browser for too long while stuck on a slow connection. It is frustrating and I do wish website owners would improve the performance of their sites. One of the reasons I set up this website was to do something about that rather than just moan about it.

Google has tried other ways to push better mobile websites. The recent so-called Mobilegeddon update to their search engine algorithm update created a lot of news and pushed people to make mobile friendly sites though the impact of this is still being argued over. Performance is also a factor in SEO, and Google do provide lots of tools to improve website performance, and now there is another proposal for how to address the issue.

AMP is a few things:

• Primarily it's a restriction on the slow parts of web technologies. While most of the focus has been on the virtual elimination of javascript, it also restricts some parts of HTML and CSS.
• It adds custom <amp> tags to fill in some of the lost functionality due to the above restrictions for limited, predefined, performant, web components.
• Ads will still be supported, but again in an limited fashion using custom <amp> tags.
• Google will add caching for AMP pages so they can be served from their servers quickly. In effect this gives you the benefits of a CDN for free.

You either agree to only use AMP technologies on your web page (which involves making some small changes to your HTML), or create a AMP compliant version of your webpage and link it on your standard web page (using the <link rel="amphtml" href="..."> syntax on your main page). More details are available on the AMP GitHub page.

AMP is intended primarily for static pages. News articles, blogs and the like. Feature rich web applications will not, and are not intended to, work in AMP - though often they are the pages that struggle the most on mobile.

AMP is being seen primarily as a response to the likes of Facebook's Instant Articles and Apple News, both of which attempt to address the same issues, but has led to fears of creating a walled garden of content away from the open Internet. Since Google's primary business model is based on the web itself, and the advertising they drive off of that, you can understand why they felt the need to come up with an alternative. As AMP is built on standard web technologies it should avoid the main downside of Instant Articles (the "walled garden" issue), however there are some that are seeing this as still a restricted web and primarily linked to one main provider - both of which are true, though to be fair to Google, they have open sourced the project to address that second issue.

It could also be a response to the current debate regarding ad blockers. With the new ability to add ad blockers to iOS9 and the increasing realisation that the website experience is being massively degraded by advertising - especially on mobile, this represents a very real risk to Google's main source of income (and of course the all important users experience argument which I'm sure is also an important motivation for Google - just not sure it's the only one, or especially the main one!). By addressing that, but still allowing advertisements which do not heavily impact performance, I would guess they are hoping to prevent a significant lose of their own revenue, and for the revenue for all the websites out there too.

Restricted web has been tried in the past. From WAP, to so called m-dot sites right up to the mobile responsive websites more and more websites are adopting. Google has also been experimenting with Google Web Light in countries with slow mobile connections, where they automatically transform websites (though there is a backlash on Google Web Light due to it's restrictions breaking websites and the fact it happens automatically without website owners even being aware, unless you specifically opt out).

That, to me, is main alternative to AMP not discussed above - simply good website coding and management. If you want to deliver a lighter website to your mobile users - then do. You don't need to impose a set of restrictions that are out of your control! Spend some time optimising your site and asking if you really need to load every external library that you currently do. You can create a mobile (m-dot) version of your website easily enough or, with a little more effort, create a proper mobile responsive website which again doesn't load everything but what it needs to.

Also, instead of improving website performance for just your mobile users (as AMP pushes you to do), why not improve your website performance for all users? Website performance does take some extra effort - there's no denying that. But in a lot of cases there are low hanging fruit (check out my top 5 performance improvements) and AMP requires extra effort anyway - so why not put that effort into tuning your main website?

While many mobiles are restricted, it's amazing the power they have, and delivering a substandard web experience rather than the best experience possible doesn't seem like the way forward to me. Apple really kick-started mobile Internet browsing when they launched the original iPhone with the full Internet on it - rather than just WAP, or some other limited Internet. AMP feels like a step backwards from this. Yes it's most of the Internet and probably what you are losing is not that much, and mobile versions of website often show you reduced content anyway, but AMP still feels like forcing restrictions that shouldn't be necessary. Maybe some restrictions should be used in certain circumstances when you're on a slow network (something like Google Web Light), but to use it all the time on mobile - regardless of whether you're on fast WiFi with no bandwidth concerns just seems unnecessary.

AMP seems to suggest the mobile web is completely broken and beyond repair, and some would agree. But I disagree and think it's merely in need of some tuning to make it better, rather than restricting it to make it more difficult to write badly performing websites.

I do think javascript is a problem for the web. After a website has loaded (a performance bottleneck in itself), javascript can be one of the main reasons for a slow, unresponsive, janky website (there's also some evidence that Google's Android platform has bigger javascript issues that iOS, which might be another reason behind Google's pushing of the AMP project).

The number of javascript libraries and frameworks has exploded and it's pretty impossible to keep up with each new one launched every day. There are many benefits to using javascript libraries: they allow quick development of rich web applications, as well as taking care of browser compatibility and reducing the risk of bugs and errors in your code. However they also can be large pieces of code, much of which you may not need. It's almost too easy to drop some javascript into a page to add some feature. Then some more for another feature. And soon it's out of control and your website is a performance hog.

There has recently been some backlash against JQuery. The aptly named youmightnotneedjquery.com website shows that often there are ways of doing a lot of what you use jquery for, in standard javascript. Don't get me wrong, JQuery's great, and if you're doing a lot of javascript, then you probably should be using it. But if you are adding the whole of JQuery, just to use one or two functions then that might be overkill. Additionally loading it on every webpage may not be necessary either. While it will (hopefully!) be cached, so it won't slow download times, the runtime and memory usage of it on the page will still be there. Javascript has come on a lot in the last few years, and other than for some of the older browsers (looking at you Internet Explorer - as usual), there is less need of the cross-browser compatibility jQuery gives you. And it's the same with other frameworks. Check whether you need them on all your pages: in particular your home page (probably one of the main pages that should be quick to load) and the pages AMP is aimed at (articles and blogs).

Taking it one step further, do you need javascript at all on a lot of your pages? HTML and CSS have come on a lot and many things that were previously only possible with javascript (e.g. drop down menu's, animation, complex styling and selectors...etc) are now possible without javascript - particularly for static pages. Ignoring third party content (which I agree is a big part of the problem), this website is built almost entirely without javascript. At the time of writing I have one function to send the star rating feedback to Google Analytics, but the rest is built on CSS and HTML alone. Granted I do use Google Analytics, Twitter buttons (though I recently moved to using my own lighter versions of them) and the Disqus commenting system on every page and these do make heavy use of javascript but they are all loaded asynchronously so do not delay the page load. Of course, this doesn't reduce the memory and CPU load of all this javascript for the browser, but the point is to be aware of the javascript used on your website and make sure you are only loading what is necessary to make your website. For now I'm comfortable with the javascript on my webpage - and I want it to show on both desktop and mobile.

There are plenty examples of bad websites out there that could do with some optimisation. One of the worst offenders you might be surprised to learn is www.ampproject.org itself:

Yes, the home page for Google's new project to performance tune the web loads 115 resources costing 2.3Mb of bandwidth (double that on desktop) and takes 12 seconds to start rendering over a 3G connection on an Android mobile! Even by their own standards it's shockingly poor:

And this is basically a static page, but they felt the need to load 125kb of Angular (45kb when gzipped), 3 custom web fonts (14kb each) and 104 images mostly for all their publisher who have joined icons, each of which takes between 4kb and 52kb. These are all loaded as separate images creating a massive latency issue on anyone not lucky enough to be using the HTTP/2 protocol they thankfully support on this site. It gets worse: it loads a 3.5Mb video continually - the same one by the looks of things! After 5mins it had downloaded 67Mb over a broadband connection. After 10 mins 127Mb and at this point I closed my browser window as I was fed up with it eating up my bandwidth and can't even image what that's doing to my browser. I mean seriously - what the hell Google?!?!?. Update 22-Oct-2015 looks like they've fixed the video issue but it's still a massive web page.

Now admittedly that page is not an AMP page, but it's still the home page of the AMP project and it's basically a static page. It's a stunning example of the very issues AMP is trying to address. I mean it's easy to pick holes in other people's code and I'm sure they could find 100 things wrong with this site, but this is shocking. I'm really not sure we should let anyone involved with this site near any mobile optimisation code! In fact one developer quickly developed their own version of the AMP project home page a quarter of the size with half the number of network calls - and worth reading the sarcastic text edits he made to the page too. While we're on the subject you really should check out that same developers talk on The Website Obesity Crisis.

Accelerated Mobile Pages Project (AMP) is an interesting concept and a lot of big names have signed up to it as can be seen at the bottom of the massive project home page. I'd also never bet against Google when it comes to web technologies, but I honestly am struggling to see the point of AMP. Why not just create a lighter webpage yourself? OK the caching part of it is an added incentive, but that's basically the same as using a CDN, which any big publisher will most likely use.

A lot of the problems that AMP aims to solve are indeed due to third party assets loaded on to the page, with overly heavy social media buttons, advertisements and javascript libraries and frameworks adding a lot of code that might not be necessary. And it's good that a project like AMP aims to address this, but since it's using the heavy handed method of basically blocking all this, then why don't website owners review whether this is really needed on their websites and benefit all their users, and not just their mobile ones? Or alternatively why not go after the core of the problem and get the third parties to improve their javascript? The official Social Media icons for example a massive performance drains when they really could be much smaller for example? Advertisements are a massive performance drain and since Google controls larges part of that they could have direct influence in creating tools to be able to create high performance ads that don't interfere with the page. Or provide better tools to show the impact each assets is having on your website - perhaps with an AMP style "look how quickly it will load without that content" demo. Without that non-AMP pages will just continue to bloat affecting the whole of the non-mobile Internet.

I also struggle to see how publishers will want to add another digital format, on top of their main website, mobile apps, Facebook Instant Articles, Apple News and whatever else they use to publish their content. And some of these require just stripping down their page to the main content, rather than converting it to another format. Yes it's basically still using web standards (though restricting some of them), but if you need to convert code to <amp> tags and test all this, then why not just improve your code?

As many other commenters have stated online: if a website is interested in performance they will likely have tuned their website and so the gains from AMP will be smaller, and if they are not interested in performance then AMP is not even on their radar. And the AMP Project's website is hardly a shining example of how this should be done - in fact it's the complete opposite!

Ultimately I think website owners should instead concentrate on tuning their website performance, rather than creating a restricted version of their website.

Do you agree? Disagree? Let me know below your thoughts below.

Despite my reservations, I've decided to have a go, to see if above opinions were unfounded and to learn a bit more about the proposal and the benefits it might bring. I've a separate blog post on implementing AMP on this site where you can read about my experiences on that and whether it changed my views on AMP.

Nearly two years on after implementing AMP I've written another post on further thoughts on accelerated mobile pages. If this article interested you then check that out for my latest opinions on that.

This page was originally created on 09-Oct-2015 and last edited on 28-Jun-2022.