Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Everything You Need To Know About Google’s Accelerated Mobile Pages

In May of 2015, Facebook unveiled its new in-app publishing platform, Instant Articles1. A month later, Apple declared that the old Newsstand2 experience (essentially a fancy folder full of news apps) would be replaced in iOS 9 with a brand new news-aggregation and discovery platform called Apple News3.

Further reading on Smashing: Link

Four months later, it was Google’s turn to announce its own, somewhat belated but no less ambitious, plan to revolutionize mobile news consumption with an open-source web-based solution called Accelerated Mobile Pages9, or AMP. In just a few months, we’ve seen the relative tranquility of mobile digital publishing erupt into yet another full-scale platform war as Facebook, Apple, and now Google compete for both the loyalty of publishers and the attention of readers.

While Facebook and Apple have a significant head start on Google, there’s every reason to believe that AMP will catch up quickly (and could even surpass one or both of its competitors). If you’re a developer or a publisher who needs to get up to speed on the why, what and how of Google’s Accelerated Mobile Pages as fast and efficiently as possible, you’re in the right place.

But What’s The Problem? Link

Before we discuss solutions, it’s worth taking a moment to explore the problem. If you do a lot of reading on mobile devices, chances are pretty good that you are already all too aware that interacting with web-based content on a phone or tablet ranges from barely acceptable to horrendous. Pages often load slowly, render erratically and behave unpredictably for two primary reasons:

  • third-party interference
    Ads and related tracking techniques not only add bulk and additional requests to an already bandwidth- and CPU-constrained device, but pages often behave as though they’re possessed as they convulse around multiple document.write() calls. The New York Times recently did a test10 that showed significant decreases in page sizes and increases in battery life after installation of an iOS content blocker11.
  • collateral damage from responsive design
    While most responsively designed websites look fine on screens of all sizes, they often contain a lot of the baggage of desktop websites when viewed on mobile. When Paul Irish12 did a performance audit of Reddit, he discovered that a great deal of the overhead could be traced back to an asset called SnooIcon13, the Reddit mascot rendered in SVG so that it could be animated (by a third-party library, meaning more overhead) on mouseover — not a situation in which assets frequently find themselves on mobile devices.

Enter Facebook Instant Articles, Apple News, and Accelerated Mobile Pages — our saviors from a world where, according to Facebook14 (PDF, 3.4 MB), the average loading time of an article on mobile devices is 8 seconds. While calling 8 seconds an eternity is obviously hyperbole, given that you could be well into your second Vine video in that amount of time, it’s probably fair to say that, by today’s standards, it’s at least an eon.

A short demo of Facebook Instant Articles, Apple News and Accelerated Mobile Pages. Note that Facebook Instant Articles and Apple News are in-app experiences, whereas AMP is entirely browser-based.

How Is AMP Different? Link

Some context for how AMP is different from Facebook Instant Articles and Apple News will make clearer some of the decisions Google made for its new digital publishing initiative.

Facebook Instant Articles and Apple News have several characteristics in common:

  • in-app experiences
    Readers access Facebook Instant Articles through Facebook on mobile devices, and Apple News is a standalone app that comes with iOS 9. Neither platform currently allows users to view articles in their specific formats outside of the respective app. Think of both as an application-specific refresh of RSS15.
  • syndication-driven
    While Facebook Instant Articles and Apple News use very different syndication formats (Apple News Format16 is JSON-based, and Instant Article Markup17 is more or less HTML wrapped in an RSS feed), they are based on similar principles: Coax your CMS into generating the necessary syndication formats, and Facebook or Apple News will slurp it up, parse it and make it both beautiful and fast through customized and optimized renderers.
  • experience-oriented
    Although Facebook Instant Articles and Apple News are both focused on performance, they are equally concerned with making articles look and feel modern. Both platforms have components that allow for the slick and smooth interactions we typically associate with bespoke, hand-built reading experiences.

In contrast, Accelerated Mobile Pages have a distinct focus:

  • web-based experience
    AMP documents are designed to be rendered either in the browser or in WebViews18.
  • atomic documents
    Although AMP documents are validated, parsed and partially rendered by the AMP runtime (plenty more on that below), they are complete and independent documents that live on your own web server (and, optionally, in a CDN cache), rather than collections of metadata that will at some point be transformed into articles and rendered in apps.
  • performance-oriented
    AMP cares far more about the performance of AMP documents than about aesthetics or interaction patterns. That’s not to say AMP documents are inherently homely (they can be just as attractive as Facebook Instant Articles or Apple News articles with the right styling), but the runtime is far more concerned with making an article render quickly than with providing fancy visual effects like crazy little jiggly things19.

What Is AMP Exactly? Link

Enough philosophizing and high-level handwaving. Let’s get into specifics. While getting your head around Facebook Instant Articles and Apple News is pretty easy (they’re essentially fancy news aggregators with custom renderers built on top of proprietary syndication formats), AMP is the outlier. It’s a little more difficult to grasp, for two reasons:

  • There isn’t a simple model to compare it to.
    When RSS was new, we all marveled at its power, wrote countless articles and blog posts about its disruptive potential, declared the home page dead20 (yet again), and then proceeded to forget all about it. Facebook Instant Articles and Apple News are essentially an RSS reboot, except that they dispense with all of the inconveniences of standards, and each happens to work in only one application.
  • AMP is not a client.
    While Facebook Instant Articles, Apple News and AMP have several elements in common, such as proprietary syndication formats and custom renderers, AMP is the only one without a dedicated client (other than the browser). More so than its brethren, AMP is a set of specifications, conventions, and technologies that can be combined into a solution, rather than being an end-to-end (publisher-to-reader) solution in and of itself.

Now that we know to think of AMP as a collection of ingredients, rather than a fully baked cake, let’s look at what those individual components are:

  • the AMP runtime,
  • the AMP cache.


AMP documents are written in HTML, but not just any HTML. Some tags are banned, while a few new tags are introduced (partially to replace the banned ones and partially to encapsulate interactive functionality). You can think of AMP HTML as what HTML would look like had it been designed with nothing but mobile performance in mind (as opposed to being introduced a full 14 years before the introduction of the iPhone).

Because AMP HTML is designed for optimal performance, to understand and appreciate its value, we need to understand the problems it solves. Here are the three biggest things that impair the loading and rendering of web pages on mobile devices:

  • payload size
    Responsive web design has served us well because it allows us to build a single website for every device and screen out there. But that also sometimes means delivering desktop-size payloads (HTML, JavaScript, CSS and assets) to extremely bandwidth- and CPU-constrained mobile devices. (Those who think of their phones as little desktop computers are giving mobile hardware far too much credit. Your iPhone 6s has 2 GB of RAM, while your laptop probably has 8 or 16.)
  • resource loading
    Resources are not always loaded in the optimal order, which means bandwidth, CPU and RAM are often dedicated to assets that users might never even see. Additionally, resources frequently don’t declare their widths and heights (especially when served through ad networks or injected via document.write() calls), which not only causes the page to resize itself as resource dimensions are lazily determined, but also triggers unnecessary and expensive layout recalculations. That’s what causes web pages to leap around like laser-chasing kittens as they ever-so-sluggishly manifest.
  • JavaScript execution
    I’m not about to broach the topic of JavaScript performance here, but modern websites often pile it on by the megabyte, and while it might execute without any discernable latency on desktop computers, mobile is still a very different environment, where, I think we can all agree, JavaScript is best kept to a minimum.

Given these three barriers to fluid web experiences on mobile devices, AMP HTML primarily exists for three purposes:

  • encourage brevity
    AMP documents are not responsive versions of desktop websites. While AMP documents can be (and usually are) responsive, they are responsive in a mobile context. In other words, rather than one page working absolutely everywhere (desktop and mobile), AMP documents are designed specifically to work well across mobile devices.
  • control external resource loading
    The AMP runtime controls the loading of external resources to ensure that the process is highly efficient, resulting in content that appears on users’ screens as quickly and intelligently as possible.
  • encapsulate interactive functionality
    Although AMP documents tend to get right down to the business of presenting readers with straightforward reading experiences, that doesn’t mean they can’t be modern and interactive. The AMP runtime provides encapsulated functionality through highly optimized JavaScript, so that developers don’t risk hindering performance by writing their own.

AMP HTML Tags Link

Below is a list of tags that are flat-out banned in AMP HTML:

  • script
    This is obviously a big one. I’ll provide more detail on AMP’s position on JavaScript below; for now, just assume that the only script tags you’ll have in your AMP documents are those loading the AMP runtime and, optionally, a tag for JSON-based linked data21.
  • base
    The base tag seems to be prohibited out of an abundance of caution, and it might end up whitelisted22 if the community complains. (My guess is that nobody really cares one way or the other.)
  • frame and frameset
    Not exactly a good use of mobile real estate anyway, so good riddance.
  • object, param, applet and embed
    Sadly, your AMP documents won’t be containing any Flash or Java applets. (That was sarcasm, in case it wasn’t entirely obvious.)
  • form and input elements (with the exception of the button tag)
    Form support will likely eventually be implemented as encapsulated components because they are of limited use23 without scripting.

Now, here’s a list of tags that replace their HTML counterparts in order to optimize resource loading and enforce best security practices:

  • amp-img24
    Replaces the img tag and optimizes resource loading by taking into account factors such as viewport position, system resources and connectivity.
  • amp-video25
    Replaces the HTML5 video tag, so that video content can be lazily loaded (taking the viewport into consideration).
  • amp-audio26
    Replaces the HTML5 audio tag so that audio content can be lazily loaded (taking the viewport into consideration).
  • amp-iframe6227
    The amp-iframe tag enforces best security practices by doing things such as sandboxing content28 by default and placing restrictions on where iframes may appear to ensure that they do not dominate an AMP document.

Finally, here are all of the tags that AMP HTML introduces to add functionality or interactivity to your documents, without requiring you to write JavaScript:

  • amp-ad29
    The amp-ad tag allows the AMP runtime to manage the loading of ads just like all other externally loaded resources (currently, ads are loaded last), and it ensures that JavaScript from ad networks can’t execute inside the parent AMP document or trigger unnecessary layout calculations. (Goodbye, document.write()!)
  • amp-analytics30
    This miniature framework packages analytics data and sends it to third-party providers. As of today, AMP support is coming31 from Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen and
  • amp-pixel32
    This is used for embedding web beacons33, and it supports tokens for sending several client variables to the server.
  • amp-carousel34
    This optimized component displays child images in an interactive, horizontal orientation.
  • amp-lightbox35
    This allows readers to open images in a full-screen “lightbox” view. It supports the specification of both thumbnail and full-sized images.
  • amp-anim36
    This loads animated GIFs and provides much-needed placeholder functionality.
  • amp-font37
    Set a loading timeout on custom fonts, and specify fallback fonts should your custom fonts not load within the allotted time.
  • amp-fit-text38
    Text within an amp-fit-text tag will automatically be assigned a font size optimized for the available space. Think of it as a little prepackaged responsiveness.
  • amp-list39
    With the amp-list tag, you can load dynamic, repeating JSON data and then render it using an HTML template. (See the amp-mustache tag below.)
  • amp-mustache40
    This supports the rendering of Mustache HTML templates41.
  • amp-install-serviceworker42
    If you choose not to use an AMP cache (much more on caching below), the amp-install-serviceworker tag loads and installs a service worker43 for the current page. Service workers are slick, but in my opinion it’s a little too early44 to rely on them.
  • amp-youtube45
    Predictably, this embeds the YouTube video with the specified video ID.
  • amp-twitter46
    Embed tweets (Twitter cards optional).
  • amp-instagram47
    Embed Instagram images.
  • amp-brightcove48
    This component loads and displays videos (and a video player) from Brightcove49.
  • amp-pinterest50
    Embed a Pinterest widget, or “Pin It” button, in your AMP document.
  • amp-vine51
    Embed the specified Vine video in your AMP document.

Note that, while amp- prefixed tags are not exactly standard HTML, they also aren’t proprietary. Rather, they are legitimate custom elements52 with JavaScript implementations that do things like enforce best security practices and prioritize the loading of remote resources (more on that in the “AMP Runtime” section below). In other words, while AMP HTML might look suspiciously like the embrace, extend and extinguish53 strategy, it’s really just a clever application of web standards and not all that much different from custom data- attributes54.

Styling AMP HTML Link

Styling AMP documents is done with standard CSS and is not much different from how you already style content. However, keep in mind several things:

  • All styling must be done with an inline style sheet — no externally linked style sheets and no element-level inline styles. (An externally linked style sheet would require an additional document to be downloaded before the layout could be calculated, and inline element-level styles could bloat the document.)
  • Styles are limited to 50 KB. Google’s philosophy is that 50 KB is enough for a nice document or article but not enough for a nice website.
  • Your inline style sheet must have the amp-custom attribute (i.e. <style amp-custom>).
  • The @ rules — @font-face (more on fonts below), @keyframes and @media — are allowed.
  • Some selectors have limitations that are known to challenge performance, such as the universal (*) selector and the :not() selector.
  • The !important qualifier is banned to ensure that the AMP runtime has the last word on element sizing.
  • Styling of custom AMP components like amp-carousel is done by overriding default classes, like .amp-carousel-button-prev, or by using a predefined set of CSS custom properties, like --arrow-color.
  • All externally loaded resources must have width, height and layout properties specified (more on layout below) to minimize expensive DOM layout recalculations.
  • Transitions and animations that can be GPU-accelerated (and that don’t trigger recalculations) are allowed. Currently, opacity and transform are whitelisted.

For additional details on styling documents, see the AMP HTML specification55.

A New York Times article formatted as an AMP document56
A New York Times article formatted as an AMP document. (View large version57)

Fonts Link

AMP happily support custom fonts, with a few qualifications:

  • Fonts must be loaded with a link tag or a CSS @font-face rule. In other words, you can’t load fonts using JavaScript.
  • All fonts must be served over HTTPS.
  • Font providers must be whitelisted. Currently, the only whitelisted providers are and But, given how quickly publishers, advertisers and analytics providers are adding support for AMP, I suspect more will follow soon.

Layout Link

AMP’s approach to layout was conceived around two main goals:

  • The runtime must be able to infer the size of all externally loaded resources before they are actually loaded, so that a final layout can be calculated as quickly as possible. Once the layout is calculated, the article can be rendered and readers can start interacting with it, even if the ads, images, audio and video haven’t completed loading yet. (And, as those resources load, they will render seamlessly, without disrupting the reading experience by updating the document’s layout.)
  • AMP articles should be responsive. As the name “Accelerated Mobile Pages” implies, AMP documents are specifically intended for mobile devices; so, in this context, “responsive” doesn’t include desktop resolutions. Rather, AMP documents should look good on all mobile devices, from those tiny old iPhone 4 relics people are still using all the way up to the relatively gargantuan iPad Pros.

The former goal is primarily achieved by the requirement that all externally loaded resources have width and height attributes (and it’s further enforced by limiting scripts, which ensures that new resources can’t be shoehorned in). The latter is achieved by standard media queries, the media attribute, the sizes attribute and the AMP-specific layout attribute.

The following is an overview of the layouts that AMP currently supports:

  • nodisplay
    The element isn’t initially displayed, but display can be triggered by a user action. (This is used in conjunction with components such as amp-lightbox.)
  • fixed
    The element has a fixed width and height, which means the runtime can’t apply any responsive behavior.
  • responsive
    In my opinion, this is the most useful and magical of AMP’s layout options. The element uses whatever space is allotted while maintaining its aspect ratio. (Basically, “Make this thing look good at any resolution, please and thank you.”)
  • fixed-height
    The element uses the space allotted but maintains a fixed height (scaling horizontally).
  • fill
    The element fills the container it’s in without regard to aspect ratio. (Think width: 100% and height: 100%.)
  • container
    The element is a container and, therefore, lets its children (as opposed to its parent) define its size, exactly like a standard div element.

Achieving a functional and straightforward document layout using AMP’s layout system is relatively easy, but when you consider everything it supports and how values apply to different types of elements, there is a fair amount of nuance. For a much more detailed breakdown, see the AMP layout specification58.

What About SVG? Link

Supported! Basic SVG enjoys comprehensive support59 across both desktop and mobile browsers, and graphics don’t get much more responsive than vectors, so AMP and SVG make a very good team. The biggest limitation is that, due to scripting restrictions, you won’t be able to animate your vectors with JavaScript — which, if we’re being honest, you probably shouldn’t be doing on mobile anyway. However, if you really must breathe a little life into your SVG, you can still do so using CSS animations, according to the same constraints outlined in the styling section above. Remember that SVG is a part of the DOM, so it can be styled — and animated — as easily as any other element.

AMP’s Philosophy On JavaScript Link

Good news and bad news here. The bad news is that you won’t be writing any JavaScript for your AMP documents anytime soon. But in a way, that’s also the good news. Keep in mind that AMP is not a mobile application framework. Rather, it’s a mobile article framework, and because articles should be optimized for seamless and fluid reading experiences, there really aren’t a lot of good use cases for heavy client-side scripting.

That being said, banning all JavaScript forever is both unrealistic and a little draconian. The reality is that the web has been relying on JavaScript for some time now — even in the context of simple and relatively bland reading experiences — for things like advertising, analytics and interactive features. Additionally, one of the best things about the web is its openness and its seemingly infinite capacity for experimentation, expressivity and creativity — a great deal of which is powered by JavaScript.

Recognizing both the burden that arbitrary, user-written JavaScript places on performance guarantees, and the ubiquity and inevitability of JavaScript in a modern web environment, the AMP team has come up with the following scripting principles:

  • No user-written JavaScript is supported or allowed at this time. You may have only two types of script tags in your AMP documents: linked data tags60 (whose type is application/ld+json) and tags for including both the AMP runtime and extended AMP components.
  • The authors of the AMP project have anticipated most of the needs for JavaScript in the context of mobile article consumption, and so AMP either supports alternatives (amp-pixel, including custom fonts with link tags or @font-face rules, etc.) or provides implementations that are compatible with the AMP runtime and that, therefore, guarantee both security and performance (amp-ad, amp-analytics, amp-carousel, etc.).
  • If you really must use JavaScript for something like an interactive feature, you can build the feature independently61 and then include it with an amp-iframe6227 tag. Content included in an amp-iframe is even allowed limited communication with the parent document for things like resizing requests.
  • AMP components are open source (Apache 263) and open to contributions, so new components will appear over time (in fact, several new components appeared over the course of writing and editing this article, so I’ve already updated a few times). While the AMP team will prioritize generalized components over service-specific functionality (a widget specifically for your social startup, for instance), it is also committed to providing enough diversity to accommodate the widest range of content possible.
  • Finally, all of these policies are subject to change. As browser features such as web workers, custom elements and the shadow DOM become more widely supported, options for supporting user-written JavaScript and custom components — while still guaranteeing security and performance — will expand dramatically.

For more information on the future of AMP components, see the “Extended Components” section of the “AMP HTML Components64” specification.

Anatomy Of An AMP Document Link

Now that you have a pretty solid understanding of AMP HTML, let’s break down a boilerplate.

Of course, you’ll start your AMP documents with a doctype declaration:

<!doctype html>

Next, designate your HTML document as AMP HTML, which, believe it or not, you do using the high-voltage emoji as an attribute in the html tag:

<html ⚡>

Or, if you’re an old-fashioned curmudgeon and bristle at the idea of adorning your code with adorable emojis, you can use the far more conservative amp attribute, instead:

<html amp> <!-- A good sign that you’re boring! -->

In your head tag, don’t forget the utf-8 character-encoding instructions:

<meta charset="utf-8">

And link to the non-AMP version of your document (marked as canonical, so that it doesn’t appear as duplicate content):

<link rel="canonical" href="my-non-amp-index.html">

Conversely, your non-AMP version should contain a reference to the AMPlified document:

<link rel="amphtml" href="my-amp-index.html">

Because AMP pages are intended for mobile devices (and you also want GPU rasterization65), be sure to include a meta viewport tag:

<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

The next line of code will seem a little strange, and that’s because it is. You know how you’ll sometimes see a web page briefly render text before the fonts have been loaded and applied, then flicker and render again looking the way the designer intended? The tag below keeps the opacity of the page at 0 (invisible) until it’s been properly styled.

body {
  opacity: 0


body {
  opacity: 1

The problem with this approach is that, should the AMP runtime fail to load, it’s technically possible for the page’s opacity never to go from 0 to 1. To compensate for such contingencies, the code above will likely be changed to something closer to this:

body {
  animation: amp-timeout 0x 5s 1 normal forwards;

@keyframes amp-timeout {
  0% {opacity: 0;}
  100% {opacity: 1;}

The next thing to do is include the AMP JavaScript runtime:

<script async src=""></script>

And include the JavaScript implementations for whichever extended components you need:

<script async custom-element="amp-youtube" src=""></script>
<script async custom-element="amp-audio" src=""></script>
<script async custom-element="amp-carousel" src=""></script>
<script async custom-element="amp-lightbox" src=""></script>
<script async custom-element="amp-anim" src=""></script>
<script async custom-element="amp-twitter" src=""></script>
<!-- etc. -->

(Note the use of the async attribute. That’s not optional — the less blocking, the better.)

Optionally, you can sprinkle in a little linked data66, like this:

<script type="application/ld+json">
  "@context": "",
  "@type": "NewsArticle",
  "headline": "Turn Your AMP up to 11!",
  "image": [ "img/cover-opt.jpg" ],
  "datePublished": "2015-01-11T08:00:00+08:00"

Now let’s add a few fonts, using either link tags or @font-face rules in your CSS:

<link href=',700' rel='stylesheet' type='text/css'>
<link href=',700,400italic,700italic' rel='stylesheet' type='text/css'>

And then we’ll some styles (no more than 50 KB worth), with the required amp-custom attribute:

<style amp-custom>

You’re now ready to build a more or less standard HTML document using everything you’ve just learned about AMP HTML.

The AMP Runtime Link

I won’t spend all that much time on the AMP runtime because, like all runtimes, it’s a bit of a black box. That’s not to say that the AMP runtime is inaccessible (it’s open source67, like the rest of the project). Rather, like all good runtimes, developers don’t need to know exactly how it works in order to take advantage of it, as long as they generally understand what it does.

The AMP runtime is implemented entirely in JavaScript and is initiated by including it in the AMP document, as you would any external JavaScript file:

<script async src=""></script>

From there, the AMP runtime primarily does three things:

  • manages resource loading and prioritization,
  • implements AMP components,
  • optionally, includes a runtime validator for AMP HTML.

The validator is critical to authoring AMP-compliant documents. It can be turned on simply by appending #development=1 to the document’s URL. Then, all you have to do is open your console to see your report card.

Errors look like this:

AMP validation errors in the console68
AMP validation errors in the console. (View large version69)

A nice, clean, compliant AMP document looks something like this:

An AMP document that passes validation70
An AMP document that passes validation. (View large version71)

The (Optional) AMP Cache Link

AMP documents can be served from a web server like any other HTML document, but they can also be served from a special AMP cache. The optional cache uses several techniques to optimize an AMP document even more:

  • Image references can be replaced with images sized specifically to the viewer’s viewport.
  • Images above the fold can be inlined to save additional HTTP requests.
  • CSS variables can be inlined to reduce client-side overhead.
  • Extended AMP component implementations can be preloaded.
  • HTML and CSS can be minified to reduce the number of bytes sent over the wire (or, in this case, the airwaves).

Anyone may run their own AMP cache on their own CDN, or publishers can use Google’s for free. Given that Google seems to know a thing or two about scalability, I’m guessing that most AMP adopters will be happy to take it up on that offer. (Documentation on how to opt in to Google’s cache is forthcoming, but given that Google already indexes and caches the Internet, it’s a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content? Link

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal72, so you do the math). In fact, Google has indicated73 that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes74). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader75!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action Link

The easiest way to see AMP in action is to check out Google’s search demo76. If you’re the trusting type, you can watch the video and just assume it all works as well as it’s depicted. If you’re more the trust-but-verify77 type, you can go to on your mobile device and try out some AMP pages for yourself (QR code below).

AMP demo QR code79
AMP demo QR code.

You can also check out the AMP experience through desktop Chrome using Chrome’s Developer Tools. All you have to do is this:

  1. Go to in Chrome.
  2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
  3. Go into device mode81 by clicking on the little phone icon in the top-left corner.
  4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)
An AMP document in Chrome Developer Tools82
An AMP document in Chrome’s Developer Tools.

Who’s Adopting AMP? Link

It’s still relatively early days for AMP, so it’s hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I’ve already seen several implementations out there in the wild, and according to the AMP FAQ83 and AMP blog8784, it’s being taken seriously by many major publishers (metered content and subscription access is currently under review85), CMS developers, advertisers, and analytics providers. I won’t list them all here because I’m sure the landscape will change almost daily, but you can keep an eye on the AMP project’s home page86 and/or the AMP blog8784 for news.

What Do I Think? Link

I’m glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it’s the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS’ have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader88, already has a plugin89 and plans on supporting AMP for all publishers90 in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it’s far too early to say which will endure and which will become the RSS of tomorrow.

Additional Resources Link

(da, jb, al)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53,_extend_and_extinguish
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77,_but_verify
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96

↑ Back to top Tweet itShare on Facebook

Christian Cantrell is a Senior Experience Development Engineer on Adobe's XD team, and a best-selling science fiction author.

  1. 1

    I have only one question and i have never find an answer to it – is AMP only for news articles, or can i use it (and get it’s advantages, e.g. better look on google) for e.g. eshop?

    • 2

      Christian Cantrell

      February 15, 2016 3:15 pm

      Hi, Tomas. AMP is definitely best suited for news articles. There’s no reason why you couldn’t use it to construct something like an online store, but you’ll find that the architecture and components are heavily biased toward articles. Keep in mind that it is meant to compete with Apple News and Facebook Instant Articles.

      • 3

        The question is, if google will show such ecommerce pages as AMP or not and it would be waste of time to try it. If they would, than the expected higher CTR (and maybe position) would be enough for me to invest our time to do it, even if it would mean limited elements, scripts etc.

        • 4

          Though you can use AMP however I don’t see that I can use everywhere exception with some static contents.

          it will be good for eshop to have a quick view of an item before it goes into the detail page. However, I don’t see any reason why one would like to build static pages when the world is going over dynamic for last two decades.

  2. 5

    Thank you for the article.

    Can you please explain a bit more how to see AMP pages in action (if I’m located not in the US/UK)? I followed the 1-4 instructions, but what is step 5, what exactly should I search in Google to find an AMP article(s)?

    • 6

      Hey Search for “mars” without quotes.

      Because not many pages have implemented AMP, if you search anything in google and there are no AMP pages for it, google won’t show them. Search for above term and you can see AMP with the news


  3. 7


    February 15, 2016 6:30 pm


    Search for “Wall Street Journal” or (shameless plug for the AMP work I’ve been doing) “Bethel College” … there should be a carousel of news articles at the top of the search results, just under where it says “This is an Accelerated Mobile Pages demo”

  4. 8

    I can’t help thinking that AMP is the solution to a problem that only exists because many developers are not optimising websites!

    I’m quoting this statement:

    “Those who think of their phones as little desktop computers are giving mobile hardware far too much credit. Your iPhone 6s has 2 GB of RAM, while your laptop probably has 8 or 16.”

    Now hold on just a minute, we’re talking *news* sites here. The BBC launched their first website in 1997. Back then, if you had 32mb of RAM, you were doing well.

    If you’re churning out *news* websites that require over 2GB of RAM, you are doing something very very wrong.

    • 9

      I don’t disagree. The things that slow down a news site usually have nothing to do with the news. Instead, they usually correspond to third-party trackers, ads, and superfluous code included for breakpoints your phone doesn’t even support.

      A lot of the benefit of AMP is simply creating a separate mobile page rather than trying to create one site that works on every single device. Responsiveness is great for developers and content creators, but if it isn’t done well, it’s sometimes not that great for end users.

      Of course, the web has legitimately gotten more complex and resource-intensive over the years. There’s audio, video, plenty of interactives, and the resurgence of massive animated GIFs.

      I think if everyone had designed sites responsibly (and with performance on all screens as an A feature), there wouldn’t have been an urgent need for things like Apple News, Facebook Instant Articles, and AMP. But unfortunately the state of the web (generally pretty inhospitable to mobile devices) brings about such initiatives.

    • 10

      I think the problem that we see today is there are too many libraries that developers feed into a simple project that may not be even required.

  5. 11

    I have done a AMP site a month ago but had some question marks which this article answered.

  6. 12

    I wonder if Aaron Swartz is rolling in his grave…

  7. 13

    Peter Tellenbach

    February 16, 2016 4:22 pm

    … optionally, a tag for JSON-based linked data.

    Google refused to index my page because there was no JSON-linked data. If you want to get your page indexed, better add it right away.

  8. 14

    Are AMP Pages a perfect idea? I am not sure.
    But AMP and SVG is a great combination.

  9. 15

    In the moment I saw the youtube and pinterest and facebook tags I was off the idea of learning this. Who creates a standard that takes into account specific products of the age? What, are they going to add a tag every time a new startup becomes famous? Instead of actually redesigning HTML, they just cherry pick what they like at this moment and the hell with the rest.

  10. 16

    James Ellis-Jones

    February 20, 2016 11:09 pm

    I really don’t know where to begin with how awful an idea this is. So Google has decided that responsive is wrong and is going to use its influence to make you write all your pages in its special arbitrarily limited HTML throwing out all your visual design principles and not letting you write the slightest bit of Javascript to, say, do something radical like open a hidden section of text when someone clicks a read more button. Javascript is evil and slow, as are useless JS plugins, so let’s force you to use OUR Javascript plugin to stop you doing bad things that hit performance, which is the only goal. Fortunately it doesn’t sound like it actually gets you viewed in any new channels and Google isn’t going to actually force you to use it by giving it search priority. If you want to be fast, just make your site fast and don’t force yourself to behave well by using a JS plugin!

    • 17

      Hey, don’t like it, don’t use it. Plenty of other ways to speed up sites.

      Personally, I’m giving it a go using WP’s official plugin. I still have some questions about a few things (e.g. can Google discover or does the plugin let Google know about the existence of the AMP’ed page? Also, is there a way to ensure these are only displayed on phones and tablets?)

      • 18

        Yup Google will automatically detect AMP pages on your site as your original page is served with a header tag directing Googlebot to your AMP page. However, you need to tweak the Plugin generated AMP theme to get your site indexed by Google. Make sure everything is AMP compliant. And once your AMP pages are detected, you can track the errors on Google Webmaster Console under Accelerated Mobile Pages section. I found this quick guide on customizing WordPress AMP theme and setting up ads and Google Analytics tracking, hope that will help.

        And yea this will only work on Mobile devices. If you want to see how it works on Mobile.. simply go to this url and search on your mobile device and you will be served with AMP pages at the top of the search results. if you are on PC, you may switch to ‘Inspect Element’ on your browser and choose Mobile View from the developer console view, load the page once again and search any keyword and Google will serve the AMP pages as it is on mobile view, but Google won’t serve AMP pages on PC mode..

  11. 19

    Farcas Gelu Danut

    March 23, 2016 8:33 am

    My WordPress website have only pages (not posts).
    AMP plugin (made by Automatic) don’t work for pages.
    Do you have solutions for this? Thank you!

  12. 20

    Sven Laucke

    May 14, 2016 11:26 am

    AMP is a big step forward for me, most of the time people go for news articles. Now this gets a speed boost and mobile internet is getting more useful. Some CMS like Drupal and WordPress support this technique already. Anyway our agency finished AMP support for the famous CMS5 as well, we will see lots of advantages for our clients to come.

  13. 21

    We are proud to introduce to you WP AMP, our brand new plugin for creating Accelerated Mobile Pages on WordPress sites:


↑ Back to top