A few weeks ago, the Accelerated Mobile Pages project was announced (press releases by Google and Twitter). This project, also known as AMP, is an open source initiative that is aiming to improve the mobile web. As most of us have experienced, pages have continued to grow in size, and often leaves a lot to be desired in terms of performance. In this post, we’ll take a quick look at what AMP is, and why publishers are paying attention.

Why AMP?

Although more and more media is being accessed via mobile, we all know that many sites are horrendous in terms of performance and user experience. Users can get frustrated, and leave the page, which in turn makes the publishers upset because they’re losing readers.

Because of the known issues, some platforms have already begun to implement ways to standardize and optimize the content they distribute within their system (for instance, Facebook’s Instant Articles). The AMP Project is similar, but instead of focusing on one specific platform, it’s seeking to create a standardized format that can be used across distributions platforms.

The hope is that publishers will publish their content in this format (along with their standard format). This optimized content will then be used by other distribution channels. In the end, the readers of the content will have fast loading content, and the publishers, in turn, more exposure.

How it Works?

Fundamental to the project is the spec for building a valid AMP page. This spec mandates that the page utilize the AMP JS library, and also restricts the HTML tags and CSS rules that can be used. For performance reasons, <img>,<video>,<iframe>,and <script> tags are disallowed. CSS rules that deal with animations and transitions are banned. The same is true of all other JS (either author written or 3rd party) are disallowed.

It’s this extreme limitation of what makes up a valid document that ensures that the content will be able to be loaded quickly. (Just imagine how quickly pages would load if there were no images, videos or 3rd party scripts.)

Here’s an example of a very basic “Hello World!” page:

<!doctype html>
  <html ⚡>
    <head>
    <meta charset="utf-8">
    <link rel="canonical" href="hello-world.html" >
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
  </head>
  <body>Hello World!</body>
</html>

In addition to the limited set of tags, there are also some custom ‘components’ (i.e. tags) that can be used to load external resources (e.g. videos, images, ads, etc.). These custom tags supplement or replace standard HTML tags, ensuring that any external resources will only be loaded at the discretion of the AMP JS library—it controls how and when these assets are loaded, not the browser.

What AMP Has Going for It

At first glance I was skeptical. Especially with the use of the AMP JS library and the creation of the custom tags. Of course, I’m all for optimized content for the web. But is this project really necessary to achieve that? The same performance optimizations could be made by publishers on their own—limiting scripts, lazy loading of content, etc—without using the AMP JS or conforming to the spec.

However, the one thing that the project has going for it is the number of companies that are collaborating on it. For instance, Google, Twitter, Pinterest, WordPress.com, and LinkedIN are among the first partners who will be integrating AMP pages into their services. For example, here’s a demo of how Google will be using AMP content in their search results. Google has also committed to cache all AMP content for free.

Add all these factors together, and publishers have a huge incentive to provide their content in this format as well. Just like publishers provide RSS feeds of their content, it’s possible that soon content will also be provided in AMP as a means of making sure their content is prioritized and visible on the main distribution channels within the growing ecosystem.

Wait and See

I still have concerns about the details of implementing the spec (i.e. using the AMP JS library, and utilizing custom tags), but I see the draw that it has for publishers. Of course, the question of how widespread the adoption of this format will be still remains. It’s early, but there are already a number of big players on board.

But how quickly it gets adopted, and to what extent? Only time will tell.

Further Reading