What drove Google to develop AMP
- The web site you’re trying to access runs on a low-power server, or it’s located far-away. Today many web pages that present you with static content actually need to call their back-end database in order for the page to load. For example if there is a comment box, a login, a plugin or microservice that’s needed for the page to load, it doesn’t matter your machine is fast. The server and its database are the bottleneck. Likewise if you are in Australia connecting to a server in Norway there is going to be some lag, even if it is an extra second, from the sheer distance and the necessary travel of data back and forth.
- The page contains heavy elements: photos, video, ad units, other scripts.
The challenge is livable on PCs with fast bandwidth. But on mobile phones we have less power, often not on high-speed WIFI. Users are frustrated with slow sites on mobile. Google and Facebook decided it was time to do something about it and both went radical in the implementation. Facebook launched Instant Articles, essentially a transformed, static copy of a web page on a site that is converted to Facebook’s HTML and markup, and stored on a Facebook content delivery network (CDN). Today FBIA only runs from Facebook, only for Mobile, and only limited content type. To Facebook’s Instant Articles, Google answered with AMP: Accelerated Mobile Pages. Welcome to AMP.
So, what exactly does AMP do?
- First, it introduces a new code set, AMP HTML. Whereas you would use standard HTML elements now a webpage needs to be marked up and formatted using AMP HTML code. To avoid requiring existing sites to recode everything Google added a second URL by appending /amp to an existing page. So now, websites running AMP have 2 URLs for posts. One is called the canonical mobile URL. the classic link. The other is called the AMP URL, and contains close to the same content, with AMP HTML instead.
- Content is made more static – at least for now. This allows Google to store copies of AMP pages on its own servers. So when a user searches in Google Search and clicks on an AMP page, that page is served not by the server of that domain. It is served by Google’s AMP cache, just like Facebook Instant Articles are served by Facebook’s Cache. Now, in the case of that user in Australia looking up that website in Norway, the AMP page for the Norwegian site will be copied on Google’s CDN cache somewhere in Asia Pacific or Oceania, and it will served much closer to the user.
- As part of AMP, file sizes are also kept to their strict minimum. Images are scaled to the device, not resized. It’s a big difference. If the webpage has an image 1000px wide, resizing means your browser will download the full size and full image, and scale it down to your screen format. Scaling means the AMP page will send the smaller version to your device, saving bandwidth and accelerating load time.
Do I need to add AMP to my site?
The short answer is, Google and search engines will make you want to create AMP pages. But in itself, if your website is already optimized for speed your users will not see a significant difference between the AMP pages and your canonical mobile pages. Because AMP is limited in functionality at the moment, accelerated pages look less sophisticated than their peers. However, Google is going to slowly but surely promote AMP pages to users, and it has started doing so by adding a small thunder icon in search results, indicating it will direct the user to the light, fast-loading AMP page copy it will serve from its CDN, not the actual website and the canonical mobile page. At the moment Google states there will be no ranking change. But let’s think about it.
Really, AMP does not affect site rankings in search?
Despite the official statement that Google has made this year, consider what makes a site rank in its search engine: Page load speed. Mobile first. The time a user spends on your page. The number of pages the user clicks on while on your site. Essentially, Google puts pages at the top of the rank if the users who come to it consume the content. How does Google know the user consumes the content? If you spend 5 minutes on a web page, if you scroll down to read more, Google tracks this. If you immediately leave the site, that is, if you “bounce”, Google also tracks this. Here are some the early results from one of our sites, laylita.com:
- Canonical Mobile Pages: the user spends an average of 3 minutes on a page
- AMP Mobile Pages: the user spends an average of 5 minutes on a page
Page load times are essentially instant for AMP. They are faster than any canonical page is going to get. Assume that the other search ranking criteria that relate to performance favor AMP pages. The more your site will serve AMP pages the more, on aggregate, the metrics Google ranks you on will improve. Provided that Google and other engines like Bing, Yahoo, Baidu, also use metrics that benefit the end user, your search engine rankings will improve by using AMP precisely because AMP is good for your site visitors and search engines rank you on these very metrics. Indirectly, AMP is likely to affect search rankings without Google changing its algorithm.
How to add AMP to your website
Where is AMP going and what’s next?
As AMP HTML evolves there is no reason why it would not replace, for the most part, its slower and bulkier predecessor. HTTP2 replaces HTTP1. CSS3 replaces CSS2. AMP can become the norm, so long as its functionality becomes on par with what we can today standard HTML. It will make sites faster, but not just faster. Over time the need for duplicating mobile pages with /amp/ may disappear. This will especially be the case if by default the standard pages use AMP HTML. AMP is also part of a broader play by Google to turn sites into apps, blending online and offline, desktop and mobile, with Progressive Web Apps (PWA).