AMP FAQ

AMP is a Google-led framework and caching infrastructure for creating fast-loading web pages. It uses a lighter and leaner version of HTML, and introduces performance-oriented HTML components that control the way media resources are loaded and used.

Custom Javascript is forbidden (although there's an experimental component to make custom Javascript possible), and CSS is rendered inline rather than in a separate file, removing the need for an additional HTTP request.

Coupled with this, AMP pages are cached and served by AMP Cache providers, including the Google AMP Cache, Bing AMP Cache and Cloudflare AMP Cache. When a reader on a mobile device clicks on a link to a page that has an AMP version — say, in some search results — the AMP version is loaded from one of these cache providers.

These things together mean that AMP pages, in general, load super fast. To a reader it can seem instant.

In the beginning, AMP pages were quite limited in the experience they could provide to the reader. However, AMP now offers a fairly rich set of components, animations and interactions. The AMP team have published an example of what's possible in AMP today (yes, the glitching effect in the title section of that page is intentional).

Note that the AMP team have also developed a "snackable" card-based visual format called AMP Stories, which are reminiscent of Facebook Stories, Instagram Stories or Snapchat Stories. These are full viewport, horizontal tap-through pages enabled by a new AMP component called amp-story. The discussion of AMP Stories deserves a whole post of its own, so we won't cover that further here.

There are several things that should interest publishers about AMP.

First, AMP pages feature prominently in search results. Google a newsworthy term (like "Trump") while on a mobile device and you'll likely see a carousel of results at the top of the page, each marked with a little lightning symbol. These are AMP page results, and if you click on one, it will load lightning fast.

Second, some of our larger news media customers report that AMP pages are responsible for upwards of 30% of referral traffic to their websites (that is, to ordinary web pages hosted on their own domains). That's a huge number that can't be ignored, and for some it's a better source of traffic than Facebook. (Note that some of these same publishers report similar referral statistics for Apple News, which is a whole other discussion!)

So regardless of a publisher's success with monetising AMP directly, it's clear that these platforms are a growing source of referral traffic. That's an important point for publishers who are determined to maintain direct relationships with their audience.

Third, AMP has its own ad format, AMP Ads, which means ads can be rendered as fast as the rest of the AMP page. Recent reports suggest that publishers are having an easier time monetising AMP directly compared to some other formats.

Fourth, they do deliver a great experience for the user. Because the pages load fast, and they're not janky — that is, they render smoothly in the browser — the user's attention remains on the substance of the page.

Fifth, AMP is open source. If Google ever stopped supporting the development of AMP, the community of developers around AMP can keep it alive. As outlined above, there are definitely benefits to the AMP format, even if the cache providers stopped caching AMP pages.

Implementing AMP is not without its downsides. Here are a few of them.

First, some commentators have pointed out the potential for brand dilution when AMP pages are featured in the carousel. Within the carousel, an article from one publisher can appear right next to another article from a different publisher.

Furthermore, once the reader has opened an AMP article from the carousel, they can swipe from one story to the next. The publisher has no control over the next story that will be shown when the reader swipes.

This was originally one of our primary concerns about AMP. Aside from providing the user with simpler navigation between articles, this experience is not altogether dissimilar from opening links in the Twitter or Facebook apps, where the page is opened in an in-app browser pane. One also needs to ask just how much more dilutive the carousel is than, say, articles from multiple publishers showing up on a search results page or in a feed. Any perceived or real brand dilution also needs to be weighed against the referral traffic generated by AMP articles.

Second, AMP pages, when opened from a Google search or the carousel or from other platforms that support AMP, appear in the browser with a URL that is not the publisher's.

So rather than example.com/amp/breaking/a-news-story, you'll see a URL like google.com/amp/example.com/amp/breaking/a-news-story. This is clearly not ideal.

This occurs because the AMP page is served from one of the AMP Cache providers mentioned earlier to enable faster loading. While there is a contentious proposal to solve this issue via a new internet standard (which is already supported in recent versions of the Chrome web browser), publishers who use AMP will need to live with this trade-off for a while longer.

Third, although there are AMP plugins for many popular Content Management Systems — making it possible to produce HTML and AMP versions of an article without additional work — the AMP renderings often leave a lot to be desired. In addition, they don't always make the best use of AMP's HTML components, leading to very "vanilla" looking mobile pages. This leads to loss of brand control.

Fourth, setting up analytics for AMP can be difficult. Although most of the commonly used analytics vendors now support AMP, it can still be tricky tracking a user session across AMP pages served from an AMP Cache and pages served from your own website. Addressing this, there is now an in-depth guide to managing user state in AMP, and some Google Analytics-specific tutorials for implementing "session stitching" (tracking sessions across different domains).

Fifth, Google may stop supporting AMP. If this happens, it's possible the AMP format itself may live on through the open source AMP project, but the caching element of AMP, which is partially responsible for AMP's speed, may presumably fade away.

Here at Shorthand, we're frequently asked to provide AMP renderings of Shorthand stories, and we've come to the conclusion that much of our original skepticism of AMP was either unfounded or overblown. In the end, we're also a customer-focused company, and we feel we can no longer ignore these requests for AMP support.

But there are major challenges for an immersive visual storytelling tool like Shorthand in supporting AMP. Chief among these is deciding how to render particular Shorthand storytelling features to AMP. How does Scrollmation render to AMP, for example?

It would be easy enough to provide a watered-down version, but even then the mapping would need to make a decision about which images to include and which to leave out. Besides, we wouldn't feel comfortable providing some audience segments with a much less immersive experience than other audience segments. It just wouldn't be very, well, Shorthand-like.

Nevertheless, we will need to make some tradeoffs, and we'll need to carefully consider how to handle things like Custom HTML sections, which often include elements that are not supported by AMP.

It's really important to note that our solution will not require customers to build separate AMP versions of their Shorthand stories. When customers choose to enable AMP for their teams in Shorthand, publishing a Shorthand story will produce the normal HTML version of the story as well as the AMP version, and the normal version will include the necessary markup to enable Google to find and cache the AMP version.

We already know there is demand from some of our customers for AMP versions of Shorthand stories. But we'd like any of our customers who are interested in publishing AMP versions of Shorthand stories to register their interest today. Please click the button below to apply to be part of our AMP beta program.