So your AMP test doesn’t perform — now what?

Editor’s note: The following was posted on Medium by Martin Schierle, Mobile Solutions Consultant at Google. 

Accelerated Mobile Pages (AMP) are a great and easy way to build very fast pages, and as we know speed is key — for every second delay in mobile page load, conversions can fall by up to 20%. So obviously the first thing people do after they built their first AMP is to A/B test it, sometimes just to find out it may not perform well…

In fact it’s not as trivial to test AMP as it may seem at first. There are a few things to be aware of when you go down the AMP path of speed, and by keeping these in mind you should be just fine!

Target Metrics

When testing AMP, different audiences often look for different metrics. Conversions are often a good target, but it’s important to keep in mind that AMP will have less impact the farther the conversion is from the AMP page. If the conversion is at the end of a 10 screen purchase funnel, it may not help much to just AMP the initial landing page, when the user might still have to navigate through nine slow pages afterwards to finish the conversion. For publishers, ad revenue is a compelling metric, but it’s often overlooked that the incremental uplift through AMP will not necessarily be seen in CPM, but rather in traffic and user engagement. For publishers it therefore makes more sense to look at revenue per session, rather than just revenue per page.

One of the most interesting and misleading metrics is the bounce rate. As page speed is directly correlated to bounce rates, and bounce rates very often directly correlate to conversions and ad revenues, this is what most people look out for when testing AMP.

And — surprise! — it’s more than likely that you’ll see higher bounce rates when testing AMP!

But why?

Survivorship Bias

It is said that when the British army introduced metal helmets in WW1, the rate of head injuries increased afterwards — which seems more than puzzling. However, giving more thought to it the reason becomes clear — a lot of the soldiers who would have died without a helmet now survived (and thus, the number of absolute injuries went up). This effect is called the survivorship bias — you only measure the ones which survived, thereby introducing bias.

The same frequently happens for slow websites — your analytics package of choice might kick in really late during the loading process, and will only measure the users which made it that far. The users bouncing before analytics fires are not seen and not measured.

Consider this graph showing the cumulative bounces over the total load time of an example page.

This page loads in 15 seconds.

We add the moment in time when the Analytics provider fires the first ping: 10 seconds.

This means that we are only measuring 20% of the visitors that are bouncing before the page is fully loaded.

If we would fire the analytics ping after 3 seconds, we’d measure 45% of the visitors that bounce before the page is fully loaded.

When putting the load times and analytics pings next to one another, we can see that the AMP page measures more of the bounces that are happening.

Even if AMP outperforms the normal page, the measured bounce rate might still be higher, since we capture more of the bouncing traffic. You can solve this by improving analytics load time on canonical, or by measuring real load abandonment as described here.

The Low Bar

In a time where most websites are too slow, it often takes really dedicated users to complete a purchase funnel on mobile — whoever is willing to wait ten or twenty seconds for a website to load, is probably very determined to finish the task she came for. So if AMP gets introduced, relative conversions might seem to go down — as the bar is now so low, that even less dedicated, loyal or interested users make it to your website who might convert less frequently. Be aware that this is still incremental traffic and incremental conversions, just that the relative conversion probability might seem lower. In these cases it might be worthwhile to also look at absolute conversions and general traffic.

App Users

Many websites offer an alternative native app which shows the same content as the website, and the mobile phone might open up the native app for URLs to this domain (but not for the same content on AMP cache). So if an app user visits a page on the AMP cache and then clicks through to regular website, the native app will open instead. As most analytics packages define a bounce as a session with only one hit, such a user flow would count as bounce — even though the user didn’t bounce but potentially finished her journey successfully in the native app.

Luckily, this scenario only applies for companies with a high app penetration in the market, but is still important to keep in mind.

Visual and Functional Parity

Historically many websites implemented AMP as a parallel version of their website, as a fast entry point from search (‘paired AMP’). In some of these cases AMP was intentionally or unintentionally not equivalent to the regular page — maybe due to oversight, maybe to save resources, or maybe the two versions got out of sync over time. However — given most companies are going through massive efforts and A/B testing to get their landing pages as optimized as possible, it seems obvious that the AMP version of the same page might not perform well, if not being functionally and visually identical (at least with respect to all critical content and user actions). For a fair A/B test, the pages need to be comparable. From a visual perspective you can use the Chrome screenshot tool to create screenshots of AMP and canonical, and compare them manually or through an image diff tool (there are many available, e.g. this one). From a functional perspective it’s worth clicking through the main user actions on both versions, and make sure they feel and behave the same way — look out especially for autofills, autocompletes, search auto correction etc.

Interaction Events

There are certain user actions on a website, which you might want to count as a successful page visit (e.g. watching a video, filling a lead form etc.). Normally a page visit with such actions is not counted as a bounce, even when the user directly leaves the page afterwards. Within Google Analytics these events are called ‘interaction events’ in contrast to ‘non-interaction events’, where a bounce is still counted. So if the regular website has many interaction events defined, but the AMP site not, this will directly influence bounce rates of both versions, and will make them impossible to compare. For Google Analytics this can be verified easily for both versions via the Google Tag Assistant Extension.

User IDs

Two of the core value proposition points of AMP are AMP Caches and Prerendering. However, the delivery from the AMP cache means the initial landing page is delivered from a different host than the regular site. Given that most analytics vendors are using first party cookies (due to third party blocks as e.g. introduced through Safari’s ITP), it means a user will be assigned two different cookies with two different user ids on her journey from AMP to canonical website. This is known to (artificially) inflate user ids, sessions and bounce rates, and is explained in more detail here.

The solution is to have a unique user ID across both hosts — AMP offers this with its AMP Linker, which can be integrated by 3rd party analytics vendors, and is also integrated in Google Analytics. However — not all analytics vendors support this, and if not implemented correctly it may fail. Then the AMP visit would be erroneously counted as a bounce, as the same user wasn’t seen again on canonical. So it’s important to verify that your analytics package is sending and using a consistent client id across AMP cache and canonical — this can be verified manually through Chrome DevTools or potentially dedicated troubleshooting tools from your analytics vendors. For Google Analytics, this can be easily checked with the Tag Assistant recording feature. Here you can navigate from search result page to AMP from cache to canonical, and then doublecheck in the recording that there is only one user session counted, which started on the AMP page, and uses the same user ids across all page hits.


So what are the things to keep in mind when testing and evaluating AMP?

  • Make sure to verify visual and functional parity (e.g. through Chrome screenshot tool and by trying all CTAs).
  • Make sure that analytics on regular mweb doesn’t fire much later than on AMP, and stay aware of the blind spot and the survivorship bias.
  • Make sure to not measure against a goal which happens much later in the funnel after the AMP page. If you measure conversions, try to focus on those happening on AMP itself (e.g. clickout).
  • Be sure to keep in mind the bias through your native app, in case it has significant market penetration.
  • Click through the whole journey from search to regular mweb, and verify that your analytics records only one user session, which starts on AMP, and uses a consistent user ID. You can do this via dedicated troubleshooting tools from your analytics provider (if available), via Chrome DevTools (look out for user identifiers in analytics pings) or via the Tag Assistant recording feature for Google Analytics.

Posted on Medium by Martin Schierle, Mobile Solutions Consultant at Google

So your AMP test doesn’t perform — now what?

Streaming in the Shadow Reader

What did we do?

We made The Shadow Reader faster again!

We created The Shadow Reader ( to demonstrate how AMP pages can be used within a Progressive Web App (PWA) (read our announcement post for more context). The site folds real articles from The Guardian into an immersive news reader experience. It’s a demo, but it’s also a fully functional site, containing everything you need to embed AMPs inside a beautiful PWA.

Earlier this year, we enhanced the Shadow Reader to follow an AMP=>AMP/PWA pattern, which made initial article loads faster and made the entire app more SEO-friendly. Now, we’ve made the site even faster by adding DOM streaming. That means the browser can render content as it loads – it doesn’t have to wait until the full load!

The video below shows the new streaming Shadow Reader on the left and the old version on the right. To clearly see the difference streaming makes, I used Charles proxy to simulate a 56kbps connection. Though this is obviously worse than the average connection, the Shadow Reader was already quite fast!  In AMPs, all JavaScript is asynchronous. And in many AMPs, including The Guardian’s, most of the HTML consists of CSS in the <head>. There isn’t that much <body> to stream! So it’s tough to spot the difference on a good connection, or even in a 3G connection simulated in DevTools.

It takes a little while to load the HTML in the <head>, so this video starts a few seconds in. Once we get to the <body>, the streaming works its magic, and in my unlablike test environment, the main article text was entirely visible 11 seconds earlier with streaming than without. Interestingly, the article’s YouTube thumbnail showed up right after the text in the streaming version, whereas in non-streaming, it showed up 67 seconds later than it did in the streaming version.



How does this work?

AMP comes in a flavor called Shadow AMP, which allows an AMP to exist entirely within a shadow root. Shadow AMP lets you embed an AMP in another webpage. You create a shadow AMP like this:

const shadowDoc = AMP.attachShadowDoc(container, doc, url);

If you’ve read Jake Archibald’s post on the subject, you know that it’s possible to stream content into the DOM via a trick involving an <iframe>. What you may not know is that this technique has been used to stream AMP content into a shadow root!  You simply create the shadow AMP with a different method:

const shadowDoc = AMP.attachShadowDocAsStream(container, url); 

Here’s how you stream AMP content into a shadow root, in 4 steps:

  1. Create the streaming shadow AMP
  2. Access your content with fetch()
  3. Stream that content into the shadow AMP.
  4. When fetch() tells you it’s done, close the writer.

The four steps

1. Create the streaming shadow AMP. See above.

2. Access your content with fetch(). Open a fetch() to the AMP URL. fetch() returns a promise that resolves to a response object. This object is a stream. Usually you’d use a method that read the stream to completion, then processed it in some way. For example, you might use response.text() or response.blob(), like this:

.then(response => response.text())
.then(text => console.log(text));

In our case, though, we’re going to use the response object as a stream. That’s easy to access via its body property, which exposes a ReadableStream.

.then(response => response.body())
.then( // read from the ReadableStream );

That ReadableStream contains a getReader() method which locks the stream and returns a ReadableStreamDefaultReader. The ReadableStreamDefaultReader exposes a read() method that provides access to chunks of HTML as they stream in, like this:

// read from the ReadableStream
let reader = response.body.getReader();
let chunk = await;

3. Stream that content into the shadow AMP.
Meanwhile, the shadowDoc we’ve created contains a writer object, and that writer contains write and close methods that can be used for streaming. So you can stream content into the DOM like this:


and close it like this:


So once we have the stream reader and the shadowDoc streamer, we repeat the following steps:

  • get chunk from stream
  • decode chunk and write it into the DOM

until the stream reader tells us it’s done, which it does through a boolean.

One way to do this is through recursion. In the Shadow Reader, we used await. Here’s the gist of our streaming code:

   const shadowDoc = AMP.attachShadowDocAsStream(container, url);
    fetch(url).then(async response => {
      let reader = response.body.getReader();
      let decoder = new TextDecoder();
      while (true) {
        let chunk = await;
        if (chunk.done) {
        let html = decoder.decode(
          chunk.value || new Uint8Array(),
          {stream: !chunk.done}
        if (html) {

4. When
fetch() tells you it’s done, close the writer. Looks like we covered that in step 3 above. And Bob’s your uncle!

Wait, you say – what about browsers that don’t yet support streaming?  Fortunately, in such cases, a call to AMP.attachShadowDocAsStream() gracefully degrades to the same functionality as AMP.attachShadowDoc().

The Shadow Reader loads and prerenders the top three articles when the app loads. We didn’t use streaming for these, and just to be on the safe side, we also don’t use streaming for browsers that don’t support it. You can conveniently compare the streaming and non-streaming approaches in the code by looking at load() and stream() in Article.js.


Reality is complicated.

What would life be without a complexity or two?

Testing. If you’re like me, you’d like to see the streaming happen, chunk by chunk, by inserting a breakpoint into the streaming code. But this may not give the desired result. At the time I’m writing this, with breakpoints set in Chrome, the shadow root remains invisible until it’s closed. You can see streaming more easily if you use DevTools to throttle your connection to 2G. It works even better to use a proxy server that sends content in smaller chunks. Or to test with an exceptionally large AMP, since many AMPs contain little HTML, and the entire content may arrive in only 2 chunks or even 1.

Order of operations. Before streaming, the Shadow Reader showed a loading spinner, loaded the article, rendered it in a hidden div, then removed the spinner and showed the article. With streaming, we want to show the article immediately!  This meant we had to move around some of the animations. It also meant that any modification of the AMP had to occur immediately, not after it fully loaded. In particular:

Hiding unwanted bits of the AMP. When the Shadow Reader imports an AMP, it needs to remove the original article’s menu, header, or footer, since those are already part of the PWA, and it would be silly to have, say, two menus. The Shadow Reader used to create the whole article in the DOM, remove the unwanted bits, then display the sanitized article. With streaming, we have to instead never show the unwanted elements in the first place. We could filter out unwanted elements as HTML came in, but this is difficult. Instead, we simply hide those elements with CSS.

Normally this is simple. AMP automatically applies an amp-shadow class to the shadow root, which allows you to easily style an AMP differently when it’s in a shadow root. Unfortunately, in our case, we don’t control the Guardian articles. We solve this by looking for a chunk that contains <style amp-custom>, and then injecting our CSS right into that.

This is useful anyway, because the Shadow Reader included a custom stylesheet in the AMP. Unfortunately, during streaming, a browser can’t be counted on to load and apply CSS as soon as it sees a <style> tag – it may wait until streaming is done. We solve this problem by injecting the custom stylesheet as well. Done!  Here’s the actual final streaming code:

    fetch(this.proxyUrl).then(async response => {
      let reader = response.body.getReader();
      let decoder = new TextDecoder();

      while (true) {
        let chunk = await;

        if (chunk.done) {

        let html = decoder.decode(
          chunk.value || new Uint8Array(),
          {stream: !chunk.done}

        // check each chunk of HTML to see if it contains <style amp-custom>. If so, add in some extra CSS.
        if (html) {
          html = shadowReader.backend.injectCSS(html);

          // when we've got the body, start the process of animating the card and showing the article,
          // placing the card before the article
          if (html.includes('<body')) {
            html = article.prependCardHtml(html);

          } else {

Left as an exercise for the reader.
At press time, I have not dealt with an edge case: this fails if <body is split between two chunks. Please submit a PR!

Posted by Ben Morss, Developer Advocate for AMP, at Google

Streaming in the Shadow Reader

The latest from AMP Analytics providers

As AMP turns three, we can’t help but look back with nostalgia on how far along we’ve come along in our mission – Build the best open web technology that lets publishers create fast and secure pages without compromising on user-experience. That is why we built the analytics infrastructure in AMP that allows for “collect once, notify many” architecture for metrics on the page. This allows for AMP Analytics to be fast and accurate while using fewer resources on mobile devices.

AMP Analytics’ interface allows third-party analytics partners to easily integrate with the service. Websites building with AMP can choose from over 55 analytics providers today to get accurate metrics of the page.

We’re continuing to invest in the ecosystem, and wanted to give a shoutout to some of the amazing providers who also continue to invest in AMP.   Over the coming few months, you’ll see deeper integrations from the following partners with AMP.

Adobe Analytics
AMP continues to be adopted by Adobe customers, who love the speed that AMP provides and the mobile first approach. Adobe has supported AMP from the beginning with two different analytics templates that customers can use based on their needs. In 2019, Adobe would like to build out more robust ID linking capabilities as well as enhance the current templates to support more events out of the box to make the implementation even easier. For customers interested in implementing AMP they can reference implementation guide.

Bizible is currently in the process of building out their AMP integration.  By next year, native event and pageview tracking will be available on AMP-enabled content.  Additionally, AMP pageviews will be considered as touchpoints for attribution across the entire customer journey.

Chartbeat was one of the inaugural analytics partners for AMP and continues to provide active support and insight to publishers around AMP traffic. Their AMP integration, as well as their trends and best practices reports, illuminates a major source of traffic for publishers and enables them to understand how engagement compares across platforms.  Chartbeat will continue to monitor AMP trends as well as broader platform shifts so they can shed light on the implications that major changes hold for publishers. For more questions about AMP capabilities or initiatives, please reach out at

Many websites use Google Analytics to better understand how well their site is meeting the needs of their users, and some sites also benefit from being able to measure campaign performance in Google Ads and Search Ads 360.  Google Tag Manager offers a solution that allows websites to instrument AMP pages with analytics tags once and make subsequent updates without touching code. For those who are not using Google Tag Manager, the recently released global site tag for AMP provides the benefit of having a single implementation for Analytics, Google Ads, and Search Ads 360.

New Relic
The New Relic Browser allows users to capture and visualize the performance of their AMP pages against their standard webpages. AMP data is captured and visualized through New Relic Insights, New Relic’s dashboard solution, to create detailed and customizable views into AMP page performance.

New Relic has plans to include AMP performance metrics into the New Relic Browser’s product in the first half of 2019. This will provide Browser customers with a clear way to compare AMP to non AMP page performance using New Relic Browser to measure if their investment in AMP is paying through page performance.  For more information, please get in touch here.

Nielsen supports measurement of static/text content on AMP as part of Digital Content Ratings, which measures digital content consumption across platforms, in every market globally where the product is available. This enables publishers to get a holistic view of their audience across the variety of distribution channels they may use, as well as the unique reach they achieve on AMP. Nielsen currently supports DCR measurement on various online video platforms and plans to extend support for native amp-video in 2019. This would allow publishers to see audience composition on AMP by content type. For further information on Nielsen’s measurement capabilities, please click here.

Many publishers today use Optimizely to A/B test article headlines, ad viewability, and subscription flows.  Optimizely is working with the AMP Project on a solution to support these same powerful experiments in AMP. This solution will allow customers to use Optimizely’s visual editor to build A/B tests and then see them take effect on AMP pages, along with measuring real-time experiment metrics through Optimizely’s Stats Engine.

Parsely fully supports measuring audiences on AMP, including the ability to support engaged time. With, content creators are able to see a single, unified view of their audience and content across multiple channels like AMP, mobile apps and website.  Soon, will support better AMP breakdowns in their API, including newer standards like AMP Stories. They are committed to support audience measurement on AMP as the standard evolves.  Please contact if you have any questions.

Tealium supports AMP in multiple ways.  One is that Tealium’s utag.js running JavaScript in an AMP iframe.  A second implementation is to host JSON on Tealium’s CDN for dynamically creating tracking beacons or defining custom event listeners.  The third is the “Tealium Collect” AMP Analytics component (current waiting merge in Github) that sends data to Tealium’s EventStream for server-side delivery of your events.

Tealium is currently working on Tealium Collect AMP Analytics component. Tealium’s Hosted Data Layer (HDL) service recently added JSON support which means that you can leverage this for definition and delivery of AMP JSON.  For questions, please go to Tealium’s Learning Community here.

As you can see from these updates, the AMP Analytics format and the number of providers supporting it continue to grow.  As updates to the format become available and new providers come online, we will update the community.

Posted by Jeff Jose, Product Manager, AMP, at Google

The latest from AMP Analytics providers

AMP story learnings and best practices

Since we announced the developer preview of AMP Stories, we’ve been focused on ensuring the format is an easy and compelling way for publishers to create visual content on the web. It’s been exciting to see the experimentation and direction that some early testers have taken with the product.

Naturally we’ve also had a lot of people asking us to share early learnings about AMP stories – what works, what doesn’t –  so we’ve tried to compile a quick run-down of best practices here:

Story Quality

1) AMP stories are just that – stories, intended to communicate a message, explain a situation, an event, a person, a concept. Publishers should be telling important stories worth reading that are both visually-rich and share relevant information in their text accompaniment. We’ve seen visual stories created in a variety of content categories, from sports to recipes to hard news to entertainment. Some things to avoid:

  • AMP stories which are just image slideshows or auto-generated are often lacking the core content that users are expecting and looking for when choosing what to read.
  • AMP stories should be complete, self-contained articles; they should make sense and be useful to the user without requiring the user to link out.

See AMP story examples from the Washington Post, and FIFA (shown above).

Example from FIFA

2) Asset Quality Matters 💯: We see dramatically better user engagement when the right assets are selected and properly formatted for an AMP story so they feel native to the experience. Beyond relevance, that means the images and videos are high-resolution, portrait-oriented, and full-bleed as it makes the experience more immersive, beautiful, and engaging to users. While we know leveraging existing assets can expedite story creation, it’s critical that the assets selected feel native to the experience and are best-suited to the dimensions of the device they are being viewed on.

Example from The Washington Post

3) Go Beyond Still Images: Some of our most engaging AMP stories incorporate short videos or Ken Burns effects to deeply engage the user. When using video, check out our video documentation on, including these tips:

  • Best practice is to use 720p, which at a 3:4 aspect ratio is 720px width by 960px height: Over-indexing on high-resolution video unnecessarily slows down the story load times for diminishing returns on quality.
  • If audio is used, it’s important that the AMP story can stand on its own with the audio turned off, given that a fair amount of consumption happens when users are on-the-go and may not want to turn audio on. For this reason the AMP framework supports captions, as well as the ability to specify whether a video contains audio via the `noaudio` attribute.
Example from WIRED 

Building an Audience & Monetizing It

4) “If a great AMP story gets created but no one sees it, did it happen?” Because AMP stories are self-canonical, the quality and relevance (across the web) is derived from the AMP Story itself. Like any other webpage, these signals are important in order to be served by platforms like Google Search. Publishers must promote their AMP Stories to users on their own homepages and sites, via social channels, and any other standard mechanisms of promotion. News publishers should consider linking from a Google News sitemap.

5) Discoverability & Indexing: There are a number of things that publishers will want to do to ensure that AMP Stories – while they may be visual-heavy – have the necessary metadata and text structure to ensure Google can discover and understand AMP stories:

  • Make all text crawlable: Use text overlays, rather than baking titles or accompanying text into images or videos themselves.
  • Apply structured data markup: Like AMP, publishers should include the appropriate structured data in addition to the AMP Story specific metadata. Note that there are unique sizing requirements for the primary thumbnail and publisher logo images specific to AMP Story documents.

6) Experiment with monetization: While it’s just been a few months since we shared public documentation on github for Single Page Ads on AMP Stories, we’ve begun to see early adoption of the format leveraging both image and video assets. We’ve also seen experimentation with ad real estate to run experiments for their own products and for their own podcasts, newsletters, etc.

AMP story ad

Tooling & Development

7) Test early and often. There are self-service tools available (Google’s AMP Test site and AMP Validation Testing Site) so publishers can test out AMP stories prior to pushing them live and identify and solve for errors. Additionally, publishers can test structured data markup here. The AMP Stories community will look to make these tools even more robust over time and would love feedback on how to make them more useful.

8) Make It Yours!: Like AMP, AMP Stories is an open-source project and its success will depend on the contributions of publishers and partners around the globe contributing feedback, requests for functionality, and even code themselves. Captions and subtitles support was added to the project by an organization that wanted support for the feature, but needed it quickly.  With a bit of guidance from the AMP team, they implemented the feature, making it available to all here.  If you have questions or thoughts, don’t hesitate to reach out to us via the right channel here.

Example of captions in an AMP story

We’re excited to continue to work with partners to evolve the format and look forward to hearing – and seeing! – from you.

Looking for more resources?

Posted by Lisa Lehman, AMP story Partnerships, Google

AMP story learnings and best practices

Child Mind Institute boosts social shares on AMP pages with AddThis

Posted by Chad Edmonds, Director of Product Marketing, AddThis 

AddThis has been excited to work with the AMP project over the past year, to ensure the web is fast and user-friendly for everyone. As AMP turns 3 years old this month, we’re celebrating the project’s progress with a recent case study showing increased shares and engagement using the AddThis AMP component. Happy birthday AMP!

Child Mind Institute is an independent, national nonprofit dedicated to transforming the lives of children and families struggling with mental health and learning disorders. The organization’s website,, provides content and resources to help those in need.

Mobile traffic has become an increased priority for the Child Mind Institute and they’ve recently implemented Accelerated Mobile Pages (AMP) to provide a better user experience for mobile visitors. Since implementing AMP in November 2017, they now see an average page speed of 3.1 seconds compared to their previous page speed of 7 seconds.

Growth from AddThis Share Buttons

AMP was a huge success, and boosting social traffic was the next step to keep the momentum going. already had AddThis Floating Share Buttons on desktop and it made sense to use AddThis for AMP and their other mobile pages. It didn’t take long for Child Mind Institute to see results—they increased shares from AMP URLs by 10% (and total shares, including non-AMP pages by 400%) and saw a 2.5% growth in new users.

Looking Forward

The digital team at is just beginning to reap the benefits of improving the mobile browsing and sharing experience. Beyond new visitor growth, increased traffic, and social shares, they’ve also seen a surge in their Facebook followers. This is a result of the huge volume of Facebook Messenger shares from their AddThis buttons on AMP. All the effort behind their mobile strategy has proved incredibly rewarding since cultivating a supportive community is an integral part of their mission as an organization. As for the future of Child Mind Institute’s relationship with both AMP and AddThis, “We can’t wait to use more of it,” Sal concludes.

Click here to view the full PDF case study

Child Mind Institute boosts social shares on AMP pages with AddThis

Three Years of AMP!


Not long ago the mobile web was sluggish, clunky and at risk of being closed off by apps. Many publishers were concerned how this would affect their future and the promise of the open web. News publishers approached us at Google to help ensure their content was easy to distribute and read across the web. To tackle these challenges, we partnered alongside publishers and tech companies on an initiative to strengthen the web, especially on mobile. Three years ago this month, together we announced the launch of the open source Accelerated Mobile Pages project.

Fast forward to today and there have been over 11,000 commits to the AMP code and the AMP project’s pledge to ensure the web is fast and user-friendly for everyone remains the same. Since its launch in 2015, AMP has grown to power billions of pages across the web from tens of millions of domains. The project has grown from a small group of dedicated committers, to the more than 700 contributors globally, with the support of hundreds of companies. And just last month, over 80 contributors met in person at the first AMP Contributor Summit.

AMP Timeline

A strong community

Since 2015, we’ve seen the community come together to participate and shape the future of the project. From the core group of companies and developers who helped launch the project, to the more than 400 developers at AMP Conf in Amsterdam, and the over 20 cities where we’ve held AMP Roadshows, we are grateful and humbled by the enthusiasm. Working together with developers who have built the AMP core code, and implement it on their own websites has been critical to the project’s growth. The new governance model announced last month will allow the project to continue to grow while ensuring constituents have a formal voice in its direction.

AMP Conf

AMP Contributor Summit

Success with AMP

Publishers and ecommerce companies continue to see positive results with AMP and grow their investment in the format. Just last week, an international mobile web study commissioned by WP Engine and conducted by Vanson Bourne found that virtually all (99%) respondents can see benefits for their organization to use AMP. They also found that 50% of those using AMP for e-commerce applications saw an increase in conversion rate. “When you factor in the real cost savings and performance increases realized by using AMP on WordPress, the results speak for themselves,” said Mary Ellen Dugan, Chief Marketing Officer at WP Engine. “The increased use of this mobile technology is resulting in much better mobile experiences at less than half the cost of apps and providing demonstrable benefits to consumers and an enterprise’s bottom line.

And last year a Forrester Consulting Total Economic Impact™ study (commissioned by Google) found that AMP led to 2x increase in time spent on page among other positive metrics. Individually, we’ve heard from many of you about your success and have had a wave of new case studies published to to highlight these wins.

New surfaces for AMP

In three short years we’ve learned a lot, but remain as energized as ever for the potential of the project. Earlier this year we announced the developer preview for AMP stories and AMP for email, two new surfaces for AMP that bring the power and speed of the AMP format to new places. AMP stories, an open format for visual storytelling on the web, in particular has grown as Google plans to incorporate stories into surfaces like Google Image Search. New features are launching soon, including increased monetization and linking options.


You could say that the AMP Project has grown at, well, the speed of an AMP page. And while progress has been swift, there is plenty of work ahead. Stay tuned to our blog this week for updates from companies and developers on their work with the AMP project, as well as best practices and tips. Finally, subscribe to the AMP newsletter, your best source for AMP updates – including AMP Conf 2019!


Happy third birthday AMP! Onwards!

Posted by David Besbris, VP of Search at Google

Three Years of AMP!

What’s new in AMP, Q4 2018

A new, open governance model for AMP

In a separate blog post, we discussed our intent to move to a new governance model for the AMP Project.

AMP Linker

For browsers that restrict third-party cookie access, AMP Linker is a new way to keep user sessions in sync. See our announcement blog post for details and how to implement them on your webpages.

“Infinite scroll” with amp-next-page

<amp-next-page> (now available as an experiment) supports what some call “infinite scroll” of articles. Developers can specify up to three URLs to load when the user gets to a specified scroll-depth in the page, and those documents will load seamlessly inline.



Tilt-bound animations with amp-orientation-observer

<amp-orientation-observer>, which supports low-level syncing between the orientation of a user’s device and frames in a given animation, is now launched. With this you can create a range of effects, like subtly shifting the background of your page, panning images, or advancing an animation on tilt. You can even create a layered 3D space by shifting multiple overlaid components of a scene at different rates.



Compare images with amp-image-slider

<amp-image-slider> gives users the ability to compare two images as overlays. This can be especially useful for “before & after” photos. Read more about that component in our recent blog post.



AMP Story Ads support with Google Ad Manager (Beta)

Google Ad Manager now supports delivering direct sold advertising by publishers to the AMP Stories they produce. You can read more about it here.

Look for the Google Pixel 2 ad as one of the story pages

The best of the rest

  • We launched several new components:
    • <amp-pan-zoom>, supports panning and zooming of inline interactive content. This helps users with a range of use cases, such as checking out details on a product image, or picking seats in an interactive seat map.
    • <amp-date-picker>, supports inputting dates and date ranges into forms. This was previously launched as an experiment, and is now generally available. More details here.
    • <amp-date-countdown>, displays a dynamic countdown to a given date and time.
    • <amp-google-document-embed> displays document files like Word documents, Excel spreadsheets, and PDFs inline in AMP pages.
  • Developers can now customize transitions in and out of the existing <amp-lightbox> component.
  • MOAT has launched beta support for instrumentation of viewability and spam detection for AMPHTML ads. Please reach out to MOAT to participate in the beta.
  • Email providers can integrate with AMP for Email using the instructions here.

Upcoming features worth a shout

  • Ever want to continue watching a video while reading an article about it, or read the directions for a recipe while watching someone actually make it? The “dock” attribute on <amp-video> will soon support minimizing video to the corner of the viewport when the user scrolls. Developers will be able to customize where and how the video docks.
  • <amp-video-iframe> will soon support a set of features available to amp-video and other third-party video components (the above minimizing video feature, for instance) for videos embedded inside of an iframe.
  • Just as AMP now has <amp-next-page> for“infinite scroll” documents, coming soon is the same behavior for page elements in a list. This will be useful for endlessly scrolling list elements like search results and product cards.
  • Input masking will soon help users fill out forms more efficiently by automatically adding formatting like spaces and interstitial characters specified by developers.
  • Support for the IAB transparency and consent framework is coming soon as part of <amp-consent> along with the ability to integrate 3rd party CMPs. If you are a CMP or publisher who’d like integrate with the IAB consent framework on AMP pages, please reach out to us on GitHub.
  • The <amp-ima-video> player is being enhanced with new features and bug fixes including adding missing mute/unmute buttons, fixing hidden controls while playing and ability to loop the video.
  • Support for sticky ads in desktop when fixed position on the left or right rail of the page

* * *

Thanks to the AMP development community for your work and feedback. As always, please let us know if you have any issues or feature requests.

Posted by Eric Lindley, Product Manager, AMP Project at Google

What’s new in AMP, Q4 2018

AMP Contributor Summit: Learnings & Takeaways

We held the first ever AMP Contributor Summit late last month, bringing together more than 80 developers from the open source community to meet each other face-to-face, talk about the latest developments in AMP and discuss where AMP should head into the future.


The summit kicked off with a New Contributor Day for people who were new to contributing to AMP.  After a series of talks covering the basics of AMP extensions and how to get code reviewed and merged, we spent the afternoon writing code.  We had 46 pull requests created on New Contributor Day alone, including many from people who had never contributed to an open source project before!  If you’re interested in contributing to AMP but weren’t able to make it to the summit, check out the New Contributor Day talks and maybe even try the beginner or advanced codelabs!


On the second day of the summit members of the community gave talks to bring everyone up to speed on the latest in AMP and to get the attendees thinking about AMP’s future.  Malte Ubl kicked off the day with an overview, and then a range of topics were covered throughout the day, including JS in AMP the proposal to change AMP’s governance model and fixing AMP URLs.  All of these talks are now available on an AMP Channel playlist.

For the last day of the summit the attendees split up into a wide variety of discussion groups.  These discussions were primarily forward-looking, focused on deep technical topics, “what’s next” for specific areas and how to make AMP better for end-users and developers using AMP.  Some examples of the topics discussed are the future of AMP Stories, improving interactivity in AMP, using AMP components outside of AMP pages and how to increase contributor diversity.  A complete list of topics with notes from most of them is available and more.


We were happy to see positive feedback from the summit attendees regarding the overall experience, the content and the sense of community that resulted from the summit.  We’re planning on having more summits like this in the future and hope to see you at one of them!

Posted by Joey Rozier, AMP Engineering Manager at Google

AMP Contributor Summit: Learnings & Takeaways

The latest results with AMP

In 2016, Australian car insurance comparison service, embarked on a website redesign. After looking at possible web frameworks to meet their needs, they chose to rebuild their website with AMP. This allowed their developer team to maintain a single code base which ensured great and fast experiences on both desktop and mobile. Since launching their entirely “AMP-first” site earlier this year, has seen a 12-15% (device dependent) increase in conversion rates on top of the expected speed gains of 15%.

greenslips_graphic saw a 12-15% increase in conversion rates isn’t alone. We’ve seen many recent examples of businesses in both the publishing and e-commerce space see success with implementing AMP on their websites. In the last month we’ve published 5 new case studies on — with more on the way. While each of these cases is unique, we hope that by sharing them, both businesses and developers can better understand how embracing AMP might benefit their own websites.

Indian publishers like The Tribune and Jagran New Media have seen revenue increases on their AMP pages, which are paired with their traditional site. In particular, Jagran New Media saw a 4.5x increase in revenue from mobile, along with an increase in traffic. Readwhere, the CMS provider used by The Tribune, is seeing both higher mobile revenue and ad viewability on their AMP pages.

Jagran New Media saw a 4.5X increase in mobile revenue

We also have seen e-commerce websites benefit from the speed and user advantages AMP can provide. Indonesian e-retailer Tokopedia has seen a 5X increase in conversions and a decrease in bounce rate from their AMP implementation. And when AMP is used with advertising solutions like AdWords, businesses often see gains from their campaigns. in particular saw a 22% increase in mobile visits and 29% more conversions from mobile devices through its Google Ads.

Tokopedia saw 5X higher mobile conversion rates

Check out the new AMP case studies below and subscribe to our newsletter to get the latest AMP Project updates in your inbox.

Have you seen success with AMP? Let us know by reaching out on Twitter or by dropping us a note in this form!

Posted by Matt Ludwig, AMP Project marketing lead at Google

The latest results with AMP

How to make AMP even faster

We’ve just published a new guide on “Optimizing your hosted AMP pages” explaining how you can optimize AMP documents so that they load even faster.

You may be thinking: wait – isn’t AMP supposed to be fast out-of-the-box? And you would be right: the AMP runtime is optimized for speed and all valid AMP pages load fast. However, there are additional performance optimizations you can implement to help the browser load AMP pages even faster. These changes are trivial, but can significantly improve loading performance without breaking AMP validity.

For example, the AMP WordPress plugin, which is being developed by XWP, already implements some of the techniques described in the guide. This resulted in the loading time for improving by 12.6%.

Another example is Evening Standard, they go one step further and publish optimized AMP with server-side-rendering (SSR). This resulted in their FCP improving by 69% over their valid AMP version.


Why should you care?

Let’s take a step back. Is this even necessary? Aren’t AMP documents always served by an AMP cache that automatically performs all these optimizations? That’s true for some cases, such as when AMP documents are surfaced in Google or Bing search results. But there are other cases were AMP documents are served from the origin:

  1. When your canonical or mobile web pages are built with AMP, such as
  2. Other platforms link to AMP documents on the origin. For example, Twitter started linking to AMP pages instead of delivering the standard mobile version. This means that if a user clicks a link in one of Twitter’s mobile apps, the link goes to the AMP version of your page on your own server.

For these cases, where you are serving AMP pages from your own servers, it is important to make sure that your AMP pages offer the optimal loading performance.


How to help the browser load AMP pages faster?

Let’s take a quick look at how optimizing AMP’s loading performance works. The AMP runtime needs to be loaded for AMP specific elements such as amp-img or amp-video to work. This means an amp-img will only start downloading an image once the AMP runtime has been loaded.

This gives us two opportunities to make AMP pages load faster:

  1. Make sure that the browser downloads the AMP runtime as quickly as possible.
  2. Tell the browser to start downloading important assets such as images even before the AMP runtime is available.

The key to achieving this is using resource hints such as rel=preload to prioritize the download of critical resources. The AMP optimization guide describes different ways how you can use resource hints to optimize AMP pages. It’s also a good idea to take a look at the AMP Boilerplate Generator which allows you to quickly generate optimized AMP templates.


How to improve first-contentful-paint?

It’s also possible to take performance optimization one step further. The AMP runtime implements a static page layout system to reduce rendering and scrolling junk. The way it works is that the AMP Boilerplate code initially hides the document until the AMP runtime is loaded. Once it’s loaded, the runtime calculates the layout and shows the content. The downside of this approach causes the user to see an empty page until the AMP runtime is loaded and it does not support progressive rendering.

To offset the negatives, first-contentful-paint (FCP) times can be improved by using AMP server-side-rendering. This way it’s possible to remove the AMP boilerplate so that the AMP document can be painted without running the AMP runtime JavaScript. For example, the server-side rendered version of the AMP Boilerplate Generator renders twice as fast as the normal AMP version:

Check out AMP Optimizer to learn how to optimize AMP documents on your server.

What are the performance gains?

To find out how optimizing affects loading performance I’ve created three different versions of the AMP Start Bike Shop template’s landing page:

    1. No Images: to simulate the best case scenario where no visual content depends on the AMP runtime being loaded.
    2. Images: to show loading times when content depends on the AMP runtime being loaded.
    3. Self-hosted Font: to demonstrate the impact loading custom fonts.

For each page, I tested four different variants:

  1. Original: the original valid AMP version.
  2. Optimized: an optimized valid AMP version, which implements the following optimizations:
    1. optimizes runtime loading
    2. preloads the hero image (when applicable)
    3. optimizes custom fonts (when applicable).
  3. Optimized + SSR: implements the same optimizations as the previous version, but additionally uses server-side-rendering via AMP Optimizer. Note: this version is not valid AMP.
  4. Cache: as a reference the version served by the Google AMP Cache.

All tests are run three times by Webpagetest in Chrome on a Motorola G (gen 4) on a 1.6 Mbps 3G connection with 300ms of latency. You can find the full results including links to Webpagetest in this doc. As tests are run on a real device, execution times might vary.

Now, let’s take a look at the results:


No Images

Load Time (s) Start Render (s) First Interactive (s)
Original 4.569 4.569 4.424
Optimized 4.564 -0.11% 4.564 -0.11% 4.423 -0.02%
Optimized + SSR 2.233 -51.13% 2.233 -51.13% 4.48 1.27%
AMP Cache 2.039 -55.37% 2.039 -55.37% 3.508 -20.71%

The >50% faster load times for the server-side rendered version clearly demonstrates the advantages of server-side rendering AMPs. However, time to interactive is unchanged as it still depends on the AMP runtime being loaded.



Load Time (s) Start Render (s) First Interactive (s)
Original 5.435 4.591 5.367
Optimized 4.591 -15.53% 4.566 -0.54% 5.094 -5.09%
Optimized + SSR 4.095 -24.66% 1.892 -58.79% 4.818 -10.23%
AMP Cache 3.827 -29.59% 1.834 -60.05% 4.13 -23.05%

Here we can see that preloading images significantly improves load times. The valid optimized AMP version loads 15% faster, whereas the Optimized + SSR version “only” loads 24% faster. This is because image rendering depends on the AMP runtime being loaded.


Self-hosted Font

Load Time (s) Start Render (s) First Interactive (s)
Original 5.509 4.609 5.424
Optimized 4.55 -17.41% 4.53 -1.71% 5.112 -5.75%
Optimized + SSR 4.478 -18.71% 1.989 -56.85% 5.203 -4.07%
AMP Cache 3.978 -27.79% 1.847 -59.93% 4.317 -20.41%

In this case, the overall load time difference between Optimized and Optimized + SSR becomes very small as the server-side rendered version is delayed by the additional font download. However, rendering still starts much faster with server-side-rendering.

Note: the AMP Cache is faster in all cases. There are two main reasons:

  1. it performs additional image optimizations
  2. it does not need to establish a second https connection to download the AMP runtimes as the runtime is served from the same domain.



We’ve seen that it’s possible to make AMP pages load even faster on your own server. The key takeaways for everyone publishing AMP pages are:

  1. Websites hosting paired AMPs should implement the recommendations in the AMP optimization guide to ensure best loading performance from Twitter and other platforms linking to non-cached AMP documents. A few trivial changes can already mean that an AMP page loads 1 second faster.
  2. Websites built with AMP should consider using AMP Optimizer as it enables progressive rendering and greatly improve FCP times.

We’re actively working on discovering new optimizations and improving the AMP loading experience.

Posted by Sebastian Benz, Partner Developer Advocate, Google

How to make AMP even faster