Should You Use Accelerated Mobile Pages (AMP)? What is Wrong With AMP and What Can You Do To Improve Your Site
Last Updated -
Accelerated Mobile Pages or AMP is a set of guidelines and web component based library to build sites that are faster than those normally developed. It was created by Google, probably as a side project by some on their search team, to help make the web faster.
From a code perspective it is an open source project, which means anyone can clone or fork the source code and manipulate it as they see fit. The project or concept is not solely championed by Google, but also enjoys support by Bing, Baidu, Twitter, Pinterest, and many other parties.
As a reward for developing your site using AMP Google 'rewards' pages with favorable search engine placement, specifically in mobile search results.
Notice how the news carousel is featured at the top of the results and there is a visual queue the page is AMP?
Many sites that have converted to AMP have reported amazing results. Not only in improved SEO, but traffic, sales and a range of other important business metrics.
But is this because they converted to AMP or merely changed their site to implement better practices, specifically making their pages load faster?
We know Google ranks faster pages higher than slower pages. I mean John Mueller and Google search team seem to always emphasize this as a key ranking signal.
So I guess there are two aspects here when you look at server speed. On the one hand there's the kind of perceived speed in the browser, in the time it takes to render a page, and that is something that is definitely a ranking factor
So improving your average page load time from say 20 seconds to 5 should improve your metrics, almost immediately.
But is AMP really the best way to make web sites?
Is it the best way to make fast web sites?
Can you make your site as fast if not faster without AMP?
One of the common perceptions about AMP is it is a way to build your site so it loads faster. But 'faster' is a relative term. As I will demonstrate in this article AMP does not really apply best practices to make pages load near instantly.
Since most pages are already too slow any improvement is better than nothing. While AMP can certainly make most pages load much faster it leaves speed on the table by not applying best practices auditing tools like Google's Lighthouse and Page Speed Tool look for.
Recent comments to an ArsTechnica article about Bing adding support for AMP demonstrate the frustration users have with bloated web pages.
It's a (bad) solution to a problem that should not exist - sites so bloated with all kinds of bullshit they use megs and megs of data just to show an article.
Plus you are outsourcing control of your web content to Google. They 'scrape' your pages and host them on their servers and their domain. They are in the process of eliminating that part sometime this year. I imagine they need to do this to avoid serious anti-trust litigation if for no other reason.
A few months ago I posted about the AMP Letter signed by myself and many of my peers concerned about AMP's direction. I think the AMP team listened and have publically stated some program changes I hope to see implemented sooner rather than later.
You absolutely want to make your pages load fast, instantly fast if you can. AMP provides some key guidelines you can follow to make your pages load faster and I love the fact Google has created another channel to evangelize something I am passionate about.
Why?
Because providing a better user experience, which by the way page load time is typically the #1 user expectation, online can lead to more positive website metrics (like serps and organic traffic) and revenue through increased engagement and customer satisfaction.
I have been catching up on Google I/O videos over the past week and there were several sessions on AMP that caught my attention. So I decided it was time to revisit AMP to see if it was really worth my time or should I stick with what I am doing.
Here's the real problem, the average web page takes about 15 seconds to load over 4G and 19-20 seconds over 3G. These numbers are important since the majority of web traffic comes from a mobile device, which of course are often not on high speed WiFi.
Because the web is essential to Google's success they decided to help everyone out by creating AMP. As an incentive you get preferential search engine placement, especially in mobile results.
Up to this point they have been targeting news sites because, let face it, news sites are the absolute worst experiences.
Seriously!
I have audited numerous news site and logged some making over 800 HTTP requests!
And weighing close to 10MB for each page.
Needles to say, they are not examples of how to build a proper web page. They are examples of how not to build a web page.
So the AMP team targeted these sites first. And there have been many positive results.
How Does AMP Work?
The AMP project provides guidelines for your to build web pages, but you must use their framework, which is, I believe, a fork of the Polymer project.
Forking is an open source concept where you take a source code repository and make your own, fresh copy, and start making your own version. This is where there are about 3 versions of Linux for every Linux user 😜.
If you are not familiar with Polymer it is a framework of web components based on, well the web components specification.
A problem with web components is until recently they were not broadly supported, this meant Polymer had to include a rather large set of polyfil code to make the project work across browsers.
This excess fat remains in the current AMP project.
There are 3 primary parts to the AMP puzzle:
- AMP HTML: A redesigned version of HTML includes a new set of custom AMP related commands.
- AMP JS: A new Javascript structure for mobile pages that allows all loading of external resources asynchronous.
- AMP CDN (Content Delivery Network): This will take your AMP-optimized content and cache them for fast delivery. You will see this refered to as AMP-Cache
AMP HTML is just a simple, minimal best practice guideline to make your page's core markup. There are some minimal requirements you need to meed the AMP standard.
- You need to designate it is an AMP page by including either amp-html or ⚡ in the opening HTML tag.
- You need to include the meta charset="utf-8" tag as the first element in the document's HEAD
- Include a minimal ViewPort directive
- Include a Canonical tag pointing to the page's orginal source URL
- Inline the core AMP CSS and any CSS the page needs
- Asyncronously load the AMP JavaScript bundle
Other than the AMP JavaScript these are all things you should do with any web page.
The AMP CDN is where Google copies your content and hosts on their servers using their internal domain, not yours. This one I have a huge issue with.
Why are they doing this?
Google spiders billions of web pages a day and knows most web servers are not properly configured. Plus most web sites are not using a content delivery network. Again these are things you can and should do.
10 years ago a CDN was only affordable by larger companies with the revenue to justify an Akamai, or one of their high priced competitors. Today the cloud has changed that. AWS, Azure, Google and others all offer affordable CDN solutions. I pay less than $0.10/month on AWS for over 60,000 unique user sessions on this site. So I think you can afford it 😁.
But the AMP JavaScript....what is this and why or why do I need to include this giant bundle of script, most of which will not be used?
As I mentioned earlier AMP is built using web components, which often require a polyfil to work because web components are not yet broadly supported. Web components relies on something called the Shadow-DOM. Right now Chrome is the only major browser offering support. And they should since they are the folks that created the concept.
Microsoft, Mozilla (FireFox) and Apple have all hesitated to implement this API. The main reason is performance concerns. I wont dive down that rabbit hole because it gets real technical. Right now FireFox is in the process of adding support. Apple has implemented some features and Microsoft is still investigating if they will invest engineering resources.
This means other than Chrome you don't have a reliable platform for Web Components. Which means AMP must ship a large bundle of JavaScript (245kb), which of course is the #1 performance killer.
I have no issues with the high level concept of web components, I think it is a good idea. But I have also had conversations with browser engineers who start to sweat thinking about making it work efficiently. I expect sometime by 2020 we may have good support, but for now let's assume there are other most important things to implement, like service workers.
I know I am in the minority, but I can typically look at most web pages and break out different UI components and conceptualize the required CSS and JavaScript to drive most of the user experience. In most cases I can see how to create most pages with less than 50kb of JavaScript, much less than the 245kb required as a base for AMP.
And that is the real issue. Too much JavaScript.
I decided to perform a simple performance audit on the AMP Project best practices page using Web Page Test. The only thing they scored poorly on was caching page assets.
Not bad...
Untill you dig a little deeper
The page does not render until 1.6 seconds, not exactly almost instantly. And this was on a desktop over a high speed connection.
Since AMP is designed to help you load faster on mobile devices I ran the same test on a Nexus 5 over an LTE connection. This should simulate an average phone on a good cellular connection.
The page does not render until 3.5 seconds!
To further prove my point about not adhering to web performance best practices I ran Lighthouse, Google page auditing tool to see how well it met its performance and best practices guidelines.
It sucked...
Several basics missed. Basically too much script and too much CSS along with unoptimized images, etc.
Not exactly near instant. I mean it is much better than the industry average of roughly 20 seconds.
Honestly I don't know why the page takes that long to at least render the markup. Just a quick review of the styles, which are properly inlined in the document HEAD should help the content render before the JavaScript is loaded. But the page does not render until all the JavaScript is loaded, parsed and executed.
You can tell this by looking at the golden rod in the CPU profile.
You should also note that any web components loaded by may also cause additional scripts to be loaded. The AMP project page has a few tiny scripts to drive different components.
I think the major delay for the page is waiting on custom font files to download before the CSS can be fully evaluated. And if you were not aware, CSS is another render blocking process.
I think there is some sort of convergence between the time it takes the rendering engine to complete the JavaScript and CSS parsing. I know I am getting into browser engine internals, which I have no direct knowledge of the internals to provide an absolute answer. But the profile tells me this is the case.
What Can You Learn From the AMP Project's Slow Page?
Minimize your reliance on JavaScript and custom fonts are the big take aways, Without this dependencies the page would render, most likely, in a second or less on the mobile phone and LTE and almost instantly over broadband.
Its hard to have a perfect page for performance. So don't dump on the AMP team completely. But I think profiling their pages help reveal why I don't think AMP is the right way to go.
What they could do is better feature detection to determine if the Shadow-DOM polyfils should be loaded or not. I did these tests using Chrome, which supports what AMP needs. So in theory I should not depend on the polyfil script being loaded, which would allow the page to load much faster with almost no JavaScript.
I will cover custom fonts in another post, so make sure you subscribe to find out about that post when it is available.
But there is more to it.
Google took it a step further and actually hosts your site on their servers, on a Google domain. This is to ensure your site's server is properly optimized to serve content as fast as possible. Plus it uses a content delivery network (CDN) to distribute the content.
Finally each site is served using HTTPS, a minimum requirement for the modern web.
There are additional rules you must adhere to, all of which are web best practices, or a minimal set of requirements every web page should implement.
How they Achieve Almost Instant Loading
One of the 'magical' parts of having AMP pages is your page loads almost instantly, if it is selected from the search result page. And that part is a key part.
In an interview with Fortune Nuzzel's Jonathan Abrams bragged about the instant loading benefit:
A page loads in less than half a second when Google's Accelerated Mobile Pages is enabled. Instead of taking three seconds to load the average page.
That sounds awesome and of course I want that too. But how does this work?
Just like the great magicians there is not any magic, just slight of hand. And I am not sure if it is Google's search result page doing magic or some coordination with Chrome. I lean toward the former, but right now I don't actually know.
The search results are pre-loaded while you are on the results page. This is great for providing faster page load experience, but brutal on the customer's bandwidth because to pull this off several pages must be loaded ahead of time. Of course the searcher will probably only chose one result.
I think part of the logic here is the AMP project JavaScript bundle is cached by the browser, so it wont need to be part of the download. And the largest part of any AMP page's initial payload is the AMP project's script bundle, which again weighs well over 250kb.
If pages have followed the AMP guidelines the actual markup payload should comfortably fit within the 14kb threshold, triggering a single URL connection to the server.
What can be problematic with this approach is skewed analytics because you would log additional user sessions, even when they do not chose your search listing. This would be logged in your server logs, not necessarily in your analytics package if you are using a JavaScript based package like Google Analytics which reports stats back to the server via an API call.
So are AMP pages the only ones getting this pre-load benefit?
Honestly I don't know. I sort of recall Bing doing something similar with results in the past. The goal is to help make the web faster. As long as the same benefit is being made to all results I don't have a problem with this feature.
Summary
While I like the core purpose of the AMP project and applaud them for helping make the web better I think they still have some work to do. Absolutely look to their guidelines as a good start to applying better practices to your site.
Like my AMP Letter friends I know you can build sites faster without AMP. I am also glad to see Google expanding the preferential treatment to other fast sites. I hope they implement this sooner rather than later. Of course they will need to provide clearer guidelines and ways to measure performance so you can I will have a clear target to hit.