Ask us a question!

Web Moves Blog

Web Moves News and Information

21
Aug
2016

Should you be AMPed about Accelerated Mobile Pages?

Earlier this year Google began including AMP listings into its mobile search results. AMP, short for Accelerated Mobile Pages, is a specification for creating slimmed down pages for mobile devices. It’s a subset of standard HTML but with restrictions. In addition, Google caches AMPs on its own CDN to provide the fastest retrieval possible. Any AMPs appearing in Google Search results are linked to these cached pages.

You may be asking yourself why we need such a thing when mobile phones are already capable of displaying “ordinary” websites. It’s a good question, and admittedly that was my first question when I first learned of AMP. The AMP project says the purpose of AMP is to give mobile users a better, faster web experience. But what’s wrong with the current user experience on mobile phones? Is it really bad enough to warrant an entire new web page specification when we already have HTML 5?

To understand how we got here, it’s helpful to take a quick look back at the history of the web.

A Brief History of Bad Design

The web has evolved quite a bit over the span of its 25 years of existence. Looking back to the web’s early days, it makes one wonder if its creators envisioned a future in which everyone carries around web-connected computers in their pockets. Web sites of the day were, for the most part, text-only scholarly papers with perhaps an image here or there.

While it’s true the early web was primitive by today’s standard, it did have an elegance that seems to be missing from the modern web. For example, consider the very first web site ever (CERN’s site about the “W3 Project”). This web site was the first settler of a new and vast frontier. It existed long before there was a Google, Facebook, or even a Netscape. Users of the time accessed this website from an early “line mode” text-based browser from their command shell. Amazingly, this first website still renders perfectly well in today’s browsers. Of course, to modern eyes it probably seems rather dull – black text on a white background lacking any sense of style or design whatsoever. However, what it lacks in appearance it makes up for in speed and simplicity. The site loads fast because it only contains the bare necessities to do what its intended to do: convey information – nothing more and nothing less. That it still renders as well today on phones, tablets, laptops, etc as it did on early 1990s command shells is a testament to the elegant simplicity of the original HTML specification.

Best Viewed with…

Best Viewed with Internet ExplorerThe frontier of the early web soon gave way to the dot-com gold rush of the late 90s and early 2000s. During this time, millions of web sites sprung up seemingly overnight. The simple and elegant text based websites of the early web began to evolve into more colorful and graphically based designs, often with garish colors, blinking text, and cheezy animated gifs. The browser wars between Netscape and Microsoft were in full swing during this time which helped fuel the explosion of bad “design.” Each browser added feature after feature trying to outdo the other, often deviating from W3C HTML standards. Designers of the era were keen to adopt these new features, some even going so far as to place a badge on their site proudly proclaiming “This site is Best Viewed with Internet Explorer.” Many of these sites were designed for specific monitor resolutions such as 800×600 or 1024×768 with inflexible layouts based on absolute pixel widths. Sadly, many such sites still litter the web today as stark reminders of the failures of this era of “web design.”

Another problem that arose was page bloat. As broadband internet access became more common, web pages became more and more bloated with javascript, flash, various ad network scripts, analytics tracking and so on. While much of this never presented a problem to PCs with fast broadband connections, for users on mobile devices, it renders a large portion of the web unusable.

The Responsive Revolution

Thankfully, web design has matured since the early days. The proliferation of mobile phones, tablets, and other devices have forced web developers to re-think how sites are designed. Gone are the days of fixed, static layouts with absolute pixel widths designed for the 4:3 aspect ratio of old CRT computer monitors. Modern sites can “adapt” or “respond” to the screen size of the device they are on. The HTML 5 specification combined with responsive frameworks such as bootstrap, foundation, and others make this “responsive design” relatively straight forward. Thus, with responsive web design visitors can get an optimal viewing experience no matter what device they’re using. Web developers have gotten smarter about page load time as well. Improved caching, CDNs, asynchronous JavaScript, and source code minification are now all considered best practices.

So what’s the point of AMP?

In short, it’s all about page load time. Google says that a lot of “ordinary” sites perform slowly on mobile devices thereby causing high bounce rates from impatient users. AMP is supposedly an attempt to remedy this situation by constraining what developers can do in order to speed up the load time of the page.

AMP pages currently focus on static content only such as news articles, blog posts, and so on. AMPs are built using a new specification called AMP HTML. Essentially it’s HTML with a laundry list of elements that must be included along with a list of prohibited HTML tags and CSS selectors. Most surprising is the restriction on including any third-party scripts. That means that no user written JavaScript may be included, nor any third party ad sctipts, analytics scripts, tracking scripts, etc. All of these constraints aim to reduce the time until the content of a page can be used by the user.

I won’t go into the entire spec here as there’s not really much to say about it. It is after all just a subset of ordinary HTML with various constraints. The full specification is here. It’s rather short and easy to understand.

How AMP Works

AMP allows you to maintain two different versions of your webpages (HTML and AMP HTML). Or, you can simply create all of your pages using AMP HTML and since they’re, for the most part, plain old HTML, they’ll render just fine in either desktop or mobile browsers. However, given the constraints within AMP HTML, this is probably not feasible for most sites. Thus, most sites will need maintain a separate set of AMP pages and make them “discoverable” by Google’s search crawler.

amp diagram

Overview of making AMPs discoverable.

The idea behind AMP “discoverability” is that for each page on your website you include a second AMP version of the page. For example, supposing you have a blog, for each blog post you’d have an ordinary web page and a separate AMP page specifically for mobile users. Thus, for each blog post you would have to separate URLs, such as:

  • http://www.example.com/blog-post (Standard web page)
  • http://www.example.com/blog-bost/amp (AMP page)

The standard web page and AMP page both point at each other. This is achieved by adding information via <link> tags within the <head> tag of each page. So, given our example, you’d add the following to the standard NON-AMP web page:

And the following “canonical” URL to the AMP page:

Google looks for the <link rel=”amphtml”> tag as it crawls the pages on your site. When it finds an AMP page, it caches it to the google “gstatic” CDN thereby ensuring that the page has the fastest hosting possible. Conversely, the <link rel=”canonical”> tag within the header of the AMP page specifies that your standard web page, hosted on your site, is the canonical url for the page.

Within Google mobile search results AMP pages are currently being given prime screen real estate above the fold in a horizontal scrolling carousel.

Should I Leverage AMP?

It depends. It does not seem as if AMP is something that can benefit every site. For example, you currently can’t implement any kind of form elements on AMP pages, so there’s no benefit for e-commerce sites, online stores, and so on. However, there are benefits for sites that publish periodical content such as news articles and blog posts. Some of these benefits include:

  • It really is fast. AMP pages load almost instantly, even on spotty cell phone connections.
  • On small mobile screens, AMP pages can be easier to read.
  • AMP listings in Google Mobile search get prime real estate above the fold.
  • Heavy duty caching on Google’s global CDN. No matter where your visitors are in the world, AMP pages will be served quickly.
  • It’s being pushed by all the big players such as Twitter, LinkedIn, Ebay, and Pinterest.
  • No messy third party ad Javascript code to install. In fact, third party JS is not allowed on AMP pages. Instead, the AMP HTML spec includes an <amp-ad> tag that works with a list of supported ad networks.
  • If you do not already have a mobile friendly site, it may be more cost-effective to implement AMP rather than make your current site mobile friendly.
  • More and more content management systems are making it easy to create AMP pages. For example, there are WordPress plugins, Drupal Modules, etc.

Back to the Future

Google’s goal of making pages load faster on mobile devices is laudable and there are some really good ideas in AMP. Despite this, AMP feels like the wrong solution for the problem it tries to solve. It’s almost as if AMP is throwing the baby out with the bath water. Is the current state of web development so broken that we need a whole new specification to address these problems? I would argue that it’s not. A lot of what AMP does can be achieved by simply following best practices for mobile web site development. Of course things can always be improved, but it seems extreme to create an entirely new specification. Especially considering there’s already a well established, decades old, standard: HTML itself. It feels like a step backwards. The wheel does not need to be re-invented.

standards

To me, as an old “web head” that’s been following this stuff for years, the history lesson above is instructive., The AMP project feels like the browser wars all over again. Instead of Microsoft shoving proprietary tags in its browser, we have Google (and the other big players) pushing AMP. But rather than mucking with a single browser, they’re tearing chunks out of HTML, calling it a specification, and hoping everyone will adopt it. Of course Google makes a lot of noise about AMP being “open,” But how open is it, really, considering huge companies with vested interests are calling the shots? The cynic in me says those “vested interests” are really what AMP is all about. Much like the Microsoft vs. Netscape war of old, Google is competing against Facebook with its “Instant Articles.” Similarly to AMP, Instant Articles are designed to load quickly on mobile devices. They’re also designed to keep users on facebook.com, which threatens Google’s real business – serving ads.

Only time will tell how AMP ultimately pans out. Those who can benefit from it will no doubt leverage it; marketers, publishers, or anyone with a lot of mobile visitors. However, in my opinion ideas like AMP represent a bleak future for the web. The web was designed to be free, open and decentralized. The AMP project seems diametrically opposed to that.