All about AMP HTML

When it got started the web was a simple stack. Do you remember dial-up internet? Content in pages was super light: images were low resolution, web pages contained very basic formatting, sometimes just plain html, and despite 1995 computer hardware power these pages and this internet worked! People posted content. We started using email. Then each year computers got more powerful. Networks got faster: you could add a bunch of code to webpages. You could call out code from outside your page, with javascript. You could put high resolution images. In spite of rapid progress in computing power and in bandwidth web pages got heavier and heavier. Fast forward to today. Some web sites load super fast. Others take forever, even if you’re on high speed internet, and even if you have the latest and greatest laptop or PC. Why?

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 calls external resources. We’ve become used to javascript to call functions located outside the webpage. These calls might go to some file located and running on the site’s server, or on some third party machine. If that’s the case the page load now depends on its server, and the servers it’s calling to do the rest of the work. The same has happened to design elements, often encapsulated in CSS files, stylesheets. It’s not uncommon that your site has a stylesheet, but also that some plugins also have their own stylesheet. Now the webpage needs to look up multiple styling elements in multiple files, sometimes on the server and sometimes online. Google in fact suggest using its online fonts, but if a site owner does this it also needs to consider making that font non-blocking. In other words, the rest of the page should load if it needs to wait for the online font to download, so that resources don’t wait on something.
• 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.
• AMP HTML is strict. Google has put together a testing tool to validate any error. In the event that an AMP page has an error it may still display perfectly fine on your computer and mobile phone, when you type the AMP URL for that page. However, Google will not index it until it passes 100% of validation. Think about the past 20 years of web development as a slippery path. Let’s just tolerate one more line of javascript here. Let’s just add one more CSS file here. Hey, it’s only one file. These add up and before we know it, we have slow mobile pages again. With AMP, the line is drawn. It is a “no compromise on speed” type of tech. It is however, a compromise on design abilities, for the initial iterations.
• Some of the things that AMP does is keep external calls to a bare minimum. There is a CSS file, but the upper limit is 1. You can use javascript, so long as it’s strictly AMP HTML compliant.
• 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

Google provides a complete documentation on how to accomplish this. If you are a developer this should look familiar, at least not fundamentally different from standard HTML or javascript. If you are not a developer you can use a content management system like WordPress, which provides a plugin for AMP. That plugin enables your site and Posts (not Pages yet, it’s under development) by creating /amp URLs that automatically convert your content into AMP HTML. Now, that conversion is done automatically and it is not work out of the box in all cases. If you are using microformats for things like recipe cook time, prep time, that format is stored differently in the database than it is rendered on your posts. You will need the plugin author to add AMP filters for those microformats to show correctly in AMP pages. As we did our AMP templates we also had to do quite a bit of formatting for things to look decent and close enough to the standard, canonical mobile experience. Because AMP only supports a single CSS we were advised that we could add custom CSS in the child theme’s functions.php file, which we did. It worked. Now, so much for the separation of styles and functions. We’re in some way back to web 1.0 with these hacks. AMP is new. How tech is implemented is going to evolve. Be ready to update your code base as things progress. By then you’ll have the advantage of having had AMP for a while. It won’t be unfamiliar territory.

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