hostmonster-Host Unlimited Domains on 1 Account   coolhandle offering reliable webhosting since 2001
Unlimited Hosting Space - FREE Site Builder   Smart Website Solutions for Your Small Business=

Turn Your AMP Up To 11: Everything You Need To Know About Google’s Accelerated Mobile Pages

Turn Your AMP Up To 11: 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.

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 Pages4, 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 test5 that showed significant decreases in page sizes and increases in battery life after installation of an iOS content blocker6.
  • 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 Irish7 did a performance audit of Reddit, he discovered that a great deal of the overhead could be traced back to an asset called SnooIcon8, 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 Facebook9 (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 RSS10.
  • syndication-driven
    While Facebook Instant Articles and Apple News use very different syndication formats (Apple News Format11 is JSON-based, and Instant Article Markup12 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 WebViews13.
  • 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 things14.

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 dead15 (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:

  • AMP HTML,
  • the AMP runtime,
  • the AMP cache.

AMP HTML Link

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 data16.
  • base
    The base tag seems to be prohibited out of an abundance of caution, and it might end up whitelisted17 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 use18 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-img19
    Replaces the img tag and optimizes resource loading by taking into account factors such as viewport position, system resources and connectivity.
  • amp-video20
    Replaces the HTML5 video tag, so that video content can be lazily loaded (taking the viewport into consideration).
  • amp-audio21
    Replaces the HTML5 audio tag so that audio content can be lazily loaded (taking the viewport into consideration).
  • amp-iframe5722
    The amp-iframe tag enforces best security practices by doing things such as sandboxing content23 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-ad24
    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-analytics25
    This miniature framework packages analytics data and sends it to third-party providers. As of today, AMP support is coming26 from Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen and Parse.ly.
  • amp-pixel27
    This is used for embedding web beacons28, and it supports tokens for sending several client variables to the server.
  • amp-carousel29
    This optimized component displays child images in an interactive, horizontal orientation.
  • amp-lightbox30
    This allows readers to open images in a full-screen “lightbox” view. It supports the specification of both thumbnail and full-sized images.
  • amp-anim31
    This loads animated GIFs and provides much-needed placeholder functionality.
  • amp-font32
    Set a loading timeout on custom fonts, and specify fallback fonts should your custom fonts not load within the allotted time.
  • amp-fit-text33
    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-list34
    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-mustache35
    This supports the rendering of Mustache HTML templates36.
  • amp-install-serviceworker37
    If you choose not to use an AMP cache (much more on caching below), the amp-install-serviceworker tag loads and installs a service worker38 for the current page. Service workers are slick, but in my opinion it’s a little too early39 to rely on them.
  • amp-youtube40
    Predictably, this embeds the YouTube video with the specified video ID.
  • amp-twitter41
    Embed tweets (Twitter cards optional).
  • amp-instagram42
    Embed Instagram images.
  • amp-brightcove43
    This component loads and displays videos (and a video player) from Brightcove44.
  • amp-pinterest45
    Embed a Pinterest widget, or “Pin It” button, in your AMP document.
  • amp-vine46
    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 elements47 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 extinguish48 strategy, it’s really just a clever application of web standards and not all that much different from custom data- attributes49.

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

A New York Times article formatted as an AMP document51
A New York Times article formatted as an AMP document. (View large version52)

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 fonts.googleapis.com and fast.fonts.net. 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 specification53.

What About SVG? Link

Supported! Basic SVG enjoys comprehensive support54 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:

For more information on the future of AMP components, see the “Extended Components” section of the “AMP HTML Components59” 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 emoji60 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 rasterization61), 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.

style
body {
  opacity: 0
}
/style

noscript

style
body {
  opacity: 1
}
/style
/noscript

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:

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

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

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

script async src="https://cdn.ampproject.org/v0.js"/script

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

script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"/script
script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"/script
script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"/script
script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"/script
script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"/script
script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"/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 data62, like this:

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

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

link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'
link href='https://fonts.googleapis.com/css?family=Lora:400,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 source63, 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="https://cdn.ampproject.org/v0.js"/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 console64
AMP validation errors in the console. (View large version65)

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

An AMP document that passes validation66
An AMP document that passes validation. (View large version67)

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 signal68, so you do the math). In fact, Google has indicated69 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 changes70). 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 Reader71!)

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 demo72. 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-verify73 type, you can go to g.co/ampdemo7674 on your mobile device and try out some AMP pages for yourself (QR code below).

AMP demo QR code75
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 g.co/ampdemo7674 in Chrome.
  2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
  3. Go into device mode77 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 Tools78
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 FAQ79 and AMP blog8380, it’s being taken seriously by many major publishers (metered content and subscription access is currently under review81), 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 page82 and/or the AMP blog8380 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 leader84, already has a plugin85 and plans on supporting AMP for all publishers86 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 https://instantarticles.fb.com/
  2. 2 https://en.wikipedia.org/wiki/Newsstand_(application)
  3. 3 http://www.apple.com/news/
  4. 4 https://www.ampproject.org/
  5. 5 http://www.nytimes.com/2015/10/01/technology/personaltech/ad-blockers-mobile-iphone-browsers.html
  6. 6 https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewInSafari/Introduction/Introduction.html
  7. 7 https://twitter.com/paul_irish
  8. 8 https://www.youtube.com/watch?v=X-qZu2Aoo98feature=youtu.belist=PLUj8-Hhrb-a1WhrhBff-_lT2EdHjHqSByt=1318
  9. 9 https://s0.wp.com/wp-content/themes/vip/facebook-instantarticles/library/docs/FB_IA_FAQS.pdf
  10. 10 https://en.wikipedia.org/wiki/RSS
  11. 11 https://developer.apple.com/library/ios/documentation/General/Conceptual/Apple_News_Format_Ref/index.html
  12. 12 https://developers.facebook.com/docs/instant-articles/guides/articlecreate
  13. 13 http://developer.android.com/reference/android/webkit/WebView.html
  14. 14 https://youtu.be/sfrnNBG28DE?t=126
  15. 15 https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=%22the%20homepage%20is%20dead%22
  16. 16 https://developers.google.com/schemas/formats/json-ld?hl=en
  17. 17 https://twitter.com/cramforce/status/663012156808425472
  18. 18 https://twitter.com/cramforce/status/663012874474811392
  19. 19 https://www.ampproject.org/docs/reference/amp-img.html
  20. 20 https://www.ampproject.org/docs/reference/amp-video.html
  21. 21 https://www.ampproject.org/docs/reference/extended/amp-audio.html
  22. 22 https://www.ampproject.org/docs/reference/extended/amp-iframe.html
  23. 23 http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
  24. 24 https://www.ampproject.org/docs/reference/amp-ad.html
  25. 25 https://www.ampproject.org/docs/reference/extended/amp-analytics.html
  26. 26 https://amphtml.wordpress.com/2015/12/09/continued-momentum-for-the-amp-project/
  27. 27 https://www.ampproject.org/docs/reference/amp-pixel.html
  28. 28 https://en.wikipedia.org/wiki/Web_beacon
  29. 29 https://www.ampproject.org/docs/reference/extended/amp-carousel.html
  30. 30 https://www.ampproject.org/docs/reference/extended/amp-lightbox.html
  31. 31 https://www.ampproject.org/docs/reference/extended/amp-anim.html
  32. 32 https://www.ampproject.org/docs/reference/extended/amp-font.html
  33. 33 https://www.ampproject.org/docs/reference/extended/amp-fit-text.html
  34. 34 https://www.ampproject.org/docs/reference/extended/amp-list.html
  35. 35 https://www.ampproject.org/docs/reference/extended/amp-mustache.html
  36. 36 https://mustache.github.io/
  37. 37 https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html
  38. 38 http://www.html5rocks.com/en/tutorials/service-worker/introduction/
  39. 39 http://caniuse.com/#feat=serviceworkers
  40. 40 https://www.ampproject.org/docs/reference/extended/amp-youtube.html
  41. 41 https://www.ampproject.org/docs/reference/extended/amp-twitter.html
  42. 42 https://www.ampproject.org/docs/reference/extended/amp-instagram.html
  43. 43 https://www.ampproject.org/docs/reference/extended/amp-brightcove.html
  44. 44 https://www.brightcove.com
  45. 45 https://www.ampproject.org/docs/reference/extended/amp-pinterest.html
  46. 46 https://www.ampproject.org/docs/reference/extended/amp-vine.html
  47. 47 http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
  48. 48 https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
  49. 49 https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes
  50. 50 https://www.ampproject.org/docs/reference/spec.html
  51. 51 https://www.smashingmagazine.com/wp-content/uploads/2016/01/01-nytimes_in_amp-opt.jpg
  52. 52 https://www.smashingmagazine.com/wp-content/uploads/2016/01/01-nytimes_in_amp-opt.jpg
  53. 53 https://github.com/ampproject/amphtml/blob/master/spec/amp-html-layout.md
  54. 54 http://caniuse.com/#feat=svg
  55. 55 https://developers.google.com/schemas/formats/json-ld?hl=en
  56. 56 https://twitter.com/cantrell/status/665172906117304320
  57. 57 https://www.ampproject.org/docs/reference/extended/amp-iframe.html
  58. 58 https://github.com/ampproject/amphtml/blob/master/LICENSE
  59. 59 https://github.com/ampproject/amphtml/blob/master/spec/amp-html-components.md
  60. 60 http://emojipedia.org/high-voltage-
    sign/
  61. 61 https://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization
  62. 62 https://developers.google.com/schemas/formats/json-ld?hl=en
  63. 63 https://github.com/ampproject/amphtml/blob/master/src/runtime.js
  64. 64 https://www.smashingmagazine.com/wp-content/uploads/2016/01/02-amp_console_errors-opt.png
  65. 65 https://www.smashingmagazine.com/wp-content/uploads/2016/01/02-amp_console_errors-opt.png
  66. 66 https://www.smashingmagazine.com/wp-content/uploads/2016/01/03-amp_console_clean-opt.png
  67. 67 https://www.smashingmagazine.com/wp-content/uploads/2016/01/03-amp_console_clean-opt.png
  68. 68 http://googlewebmastercentral.blogspot.com/2015/04/rolling-out-mobile-friendly-update.html
  69. 69 https://amphtml.wordpress.com/2015/12/09/continued-momentum-for-the-amp-project/
  70. 70 https://amphtml.wordpress.com/2015/12/14/building-a-faster-mobile-web-experience-with-amp/
  71. 71 https://www.google.com/reader/about/
  72. 72 http://insidesearch.blogspot.com/2015/10/accelerated-mobile-pages-in-search.html
  73. 73 https://en.wikipedia.org/wiki/Trust,_but_verify
  74. 74 http://g.co/ampdemo
  75. 75 https://www.smashingmagazine.com/wp-content/uploads/2016/01/04-amp_demo_qr-opt.png
  76. 76 http://g.co/ampdemo
  77. 77 https://developer.chrome.com/devtools/docs/device-mode
  78. 78 https://www.smashingmagazine.com/wp-content/uploads/2016/01/05-wsj_in_dev_tools-opt.jpg
  79. 79 https://www.ampproject.org/faq/
  80. 80 https://amphtml.wordpress.com/
  81. 81 https://amphtml.wordpress.com/2015/12/09/continued-momentum-for-the-amp-project/
  82. 82 https://www.ampproject.org/
  83. 83 https://amphtml.wordpress.com/
  84. 84 http://venturebeat.com/2015/11/08/wordpress-now-powers-25-of-the-web/
  85. 85 https://vip.wordpress.com/2015/10/07/mobile-web/
  86. 86 https://amphtml.wordpress.com/2015/12/09/continued-momentum-for-the-amp-project/
  87. 87 https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
  88. 88 https://www.ampproject.org/
  89. 89 https://amphtml.wordpress.com/
  90. 90 https://github.com/ampproject/amphtml
  91. 91 https://www.ampproject.org/docs/get_started/about-amp.html
  92. 92 https://www.youtube.com/watch?v=KOO5S4vxi0o
SmashingConf Oxford

Hold on tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Oxford, on March 15—16, with smart design patterns and front-end techniques.

↑ Back to top
Tweet itShare on Facebook

Article source: https://www.smashingmagazine.com/2016/02/everything-about-google-accelerated-mobile-pages/

Tags:


Submit a Review




If you want a picture to show with your review, go get a Gravatar.

1&1 has shared hosting and dedicated hosting solutions for every budget and free domains with all hosting packages!  StartLogic - Affordable hosting: Free setup/domain, unlimited emails, PHP, mySQL, CGI, FrontPage. As low as $3.95/month
Cloud ecommerce platform delivers more traffic, higher conversion and unmatched performance

© Copyright 2008 Tyconia International, Inc. All Rights Reserved.