Live-updating AMPs

[9/1/2016 Update: has been promoted from “experimental” to “stable”, and can now be used in production pages. Check it out, try it out and give us feedback!]

More and more publishers are leveraging the power of live blogs to connect readers to breaking news as it unfolds. Today we are inviting you to try out the beta for , a new AMP component that updates page content dynamically without additional navigation or reload: readers looking at an earlier version of the page will simply see new updates as they come in.


You—as a developer—have control of the content, and can override the component’s default styles. For example, a default class is applied to the most recent updates, so you can determine the style of new items, such as subtly highlighting the background for new items for a few seconds. The component also includes a customizable button for your users to pull in updates on demand.

How does it work?

In the background, while an AMP page using is displayed on the client, polls the origin document on the host for updates. When the client receives a response, it then filters and dynamically inserts those updates back into the page on the client. Publishers can customize the polling rate in order to control the number of incoming requests, and AMP caches like the Google AMP Cache can perform optimizations to reduce the server response payload, saving client bandwidth and CPU cycles.


To use , all you have to do is:

  1. While the component is in beta, opt into the experiment by entering

    into your javascript console on your testing page. You can also opt in on the AMP experiments page for all pages served from

  2. In the HTML for an AMP page, wrap any live-updating content in and its children, ensure that each element has the required attributes and structure, and publish the page.
  3. Whenever new information comes in, update the HTML for with new entries or changes to older entries, and re-publish the page.

That’s it! The child elements of will be dynamically updated as new content comes in.

Example implementation

<amp-live-list id="live-list" data-poll-interval="20000" data-max-items-per-page="10">
<div update on="tap:live-list.update">
You have updates</div>
<div items>
<div id="live-list-item-2" data-sort-time="1464281932879">world</div>
<div id="live-list-item-1" data-sort-time="1464281932878">hello</div>

Why beta?

This is a very flexible format: on one hand, you could use it for live blogs, which feature updates across nearly the entire page, and can include details like pagination or deep-linking to specific posts. On the other, you might use it to update just one small section, like a scoreboard during a soccer game, or a map of voting results on the night of an election. With your feedback from testing real-world applications of the component, we have the opportunity change some of the behaviors and validations before launch.

This of course means that you shouldn’t launch it on a public-facing page until progresses to “stable” status, and that you should expect to see some validation errors associated with the component while you’re testing.

Try it out!

So check out the documentation in GitHub and at AMP by example, test out the component in your development environment, and give us feedback for what does and doesn’t work for your use-cases. The sooner we know what is and isn’t working for , the sooner we can polish it up and release it to production for use in your AMP pages.

Posted by Eric Lindley, Product Manager

Live-updating AMPs

Using machine learning to predict drivers of bounce and conversions on mobile

Earlier today, Daniel An and Pat Meenan from Google shared the results of a recent research project focused on uncovering what influences the bounce and conversion rates for e-commerce sites.

Using a machine learning model developed in collaboration with SOASTA, Daniel and Pat identified that the speed and performance of a website can significantly influence the bounce rate of an e-commerce site.  To put it simply: the slower and the more complex the page, the higher the bounce rate and the lower the conversion rate. This is consistent with several research studies and shows the promise that AMP adoption in e-commerce sites holds for doing business on the mobile web.


Source: Google/SOASTA Research, 2016.


To read more about Daniel and Pat’s research check out their article on Think with Google. And if you are curious to learn more about how your website is performing, we encourage you to run the same analysis using their open-sourced code.

Using machine learning to predict drivers of bounce and conversions on mobile

But what about the ads?

This is the story about how AMP came to build a user-experience-first ecosystem for advertising on the web.

A significant part of my job working on the AMP Project has been to engage in discussions on Twitter and in our GitHub issues around what AMP is, what it should be and whether it is doing the right things. Often these discussions eventually come to a point where somebody says:

“Cool, you made the content faster, but what about the ads? Aren’t they the worst offenders for page load times?”

AMP’s original goal was to lift up the user experience across as much web content as possible. This meant we couldn’t just build some idealistic system–existing monetization methods would need to be supported in order to get the wide adoption that would lead to widespread user experience improvements. On today’s web that meant: AMP had to support advertising.

I learned a lot about internet advertising in the first months of working on AMP, and one of those things was that the web advertising industry doesn’t exactly change fast. In fact, looking at lots of ad related JavaScript on the web, one cannot avoid frequent 90s flashbacks.

That led to the design compromise in AMP: Support legacy web advertising, but do so in a way that would mitigate impact on the pages it is embedded into. To achieve this goal AMP uses the following techniques:

  • Content first. AMP loads ads after the rest of the content, so ads would never slow down load time.
  • Containment. AMP strictly manages the area of a page that ads can access and control to a well defined rectangle. Among other things this avoids pages “jumping around” as ads pop in.
  • Mitigation. AMP mitigates against various JavaScript worst practices often found in ad tech such as `document.write`, by limiting their effect on the ad itself vs. the entire page.
  • Intervention. AMP slows down timers such as those used for animations for ads that are not currently visible, so that ads use much less battery and CPU when they aren’t being seen. Firefox, Safari, Opera and Chrome have recently started doing this by default and we’ll be happy to delete the code when this rolls out to more users. Because in AMP all legacy ads run inside iframes (many ads outside of AMP have access to the host page), these new browser interventions work particularly well in AMP.

These measures, together with AMP’s aggressive optimizations for general web content, significantly improve both page load time and mitigate effects of the ads on the user experience. In particular, the fact that content always loads first guarantees that ads are never in the way of users doing what they came for on a given page.

There are, however, limits to the fidelity that can be achieved with the approach we have taken so far. This starts with the obvious: Delaying ad load until after content might be an OK compromise, but it is far from the best possible strategy one could employ with finer grained control over an ad’s lifecycle. But the biggest issue, which AMP so far has not addressed, is what we call the coordination problem.

The coordination problem

Source: Daniel Stockman, License: CC BY-SA 2.0

One of the greatest strengths of the web is that it has a super flexible composition model. This allows easy and ad-hoc assembly of things like YouTube videos, Instagrams, Tweets and ads on a single page. But while composition is simple, all these components share a single thread for JavaScript computation and most UI operations. This is where the coordination problem comes into play: While each component, in isolation, might work super well, things can easily deteriorate to bad UX when assembled together.

This is a frequent problem with ads. For instance, it is super easy to envision 3 ads that each use 6ms of CPU per frame for their animations. That is in itself great — easily staying within the frame budget to achieve 60 frames per second (or 16ms total frame time). But when those ads appear together on the same page, they suddenly need 18ms per frame and the browser can no longer deliver the smooth experience of 60 frames per second.

That is the coordination problem: Even perfectly engineered ads can, in aggregation, negatively impact user experience.

Finally, even ignoring the above, there is a lot that can be done to improve overall quality of ad creatives in terms of their impact on user experience. AMP was first created as a simple path to creating well performing documents on the web, and it seems that it would be great to make that same leap forward for advertising on the web.

Introducing AMP for ads

Earlier this year, a team at Google asked themselves the question:

“AMP worked super well for general content. Couldn’t we just use it for ads?”

…which is what they did. These ads based on AMP are normal, valid AMP documents in their own right, that just happen to be ad creatives. I’m super excited about this as it provides a path to solving all the technical challenges outlined above, bringing us to a more technically healthy advertising ecosystem on the internet.

It is early days for AMP for ads, or A4A, but after announcing the effort on GitHub a few weeks ago, the team has merged their pull request into AMP and is in the process of setting up a live experiment. AMP itself will continue to support non-AMP ad creatives to allow for a gradual transition of the wider ecosystem.

Separating ad requests from ad rendering

The first innovation in A4A seems very obvious in retrospect, but has a super large impact: As outlined above, AMP, by default, loads ads after the content and generally lazily. This is because rendering ads can be expensive in terms of CPU and RAM. However, the ad request itself can be slow, because a lot of work (think: the auction) has to be done on the server side — doing it late is not great for fast load times. From the client’s perspective making the request itself is super cheap, but its side effect (the rendering of the ad) is expensive. By separating the two, A4A achieves much faster ad rendering at no additional CPU and memory cost.

A4A_Good3G_v02 (1)
Example video of the performance improvements that A4A brings to simple ads.

Going deeper: A restricted subset of AMP

One of the core elements of AMP is that is ships with a validator, that checks compliance of AMP documents with certain rules. The idea is: If the rules are met, then the document will load fast. The ruleset we designed for AMP has a broad set of document types and use cases in mind. Ad creatives, on the other hand, are a much more focused use case, and hence they do not actually require the full breadth of functionality that AMP exposes. For this reason, AMP for ads carefully picks out the aspects of AMP that are required to build ad creatives. One example is that AMP based ads will not be allowed to load iframes with arbitrary JavaScript.

Contrast this with the status quo in ad tech: ad creatives typically have full control over the browser and they can dynamically load more code at runtime, so it is impossible to ever really know what they will do. AMP based creatives on the other hand will have well defined, statically analyzable behavior while still having access to the vast majority of web platform functionality.

AMP being optimized for documents right now is certainly missing many types of components needed for engaging ads. The team is hard at work at closing that feature gap. One example is that AMP for ads will ship with a component for smooth and interactive timeline based animations.

Re-using AMP

Ads often come with their own set of measurement tools to collect important information such as whether an ad was actually seen by a user. This substantially increases ad payload size, initial compilation and execution time, battery usage and other aspects of runtime performance.

AMP, through its established `amp-analytics` mechanism, already ships with all the code to perform these measurements. It is vendor neutral and supports a wide range of metrics. This means ads can take advantage of the same “instrument once, report many times” feature that benefits AMP pages today, completely eliminating the bandwidth and runtime cost outlined above.

The coordination solution

Source: Daniel Stockman, License: CC BY-SA 2.0

AMP based ads will participate in page layout like all other AMP resources. That means they automatically take advantage of AMP’s features for minimizing resource impact on runtime performance.

In particular, AMP only animates things that are visible on the screen. Period. While browsers are working on achieving this at the platform level, they need to be conservative in not breaking existing use cases. AMP for ads being new and special purpose technology, can pinpoint when animations are needed and thus further reduce CPU usage and battery consumption.

AMP will act as a supervisor for ads and ensure that they do not negatively impact primary content on a page. A4A based animations will be throttled to lower-but-uniform frame rates when AMP detects that 60 frames per second cannot be achieved on the current device. Similarly, if AMP is unable to stabilize the frame rate it will turn off animations. This ensures that every device gets the best experience it can deliver and makes sure that ads cannot have a negative impact on important aspects of the user experience such as scrolling.

Cross platform

As part of the AMP Project, AMP for ads is a vendor neutral initiative. While we are still in the early experimentation and implementation phase, the technology is designed to support all ad networks. If you work on ad tech, say Hi on GitHub. We believe A4A is a big step forward for user experience and would love to see wide adoption across the internet advertising industry.

So, that is what we are doing with ads

It is early days, and we are just getting started to explore using AMP for ads.

In this future

  • ads will be statically analyzable to be safe and behave well,
  • they will be able to use a common set of functionality to significantly reduce bandwidth consumption,
  • CPU usage will be limited to on-screen ads, maximizing battery life,
  • and ads will be coordinated with the page making sure that primary content and functionality can always be buttery smooth at 60 frames per second.

We are trying to build a user-experience-first ecosystem for advertising on the web and, looking at the success of AMP in publishing, it might just work.

This post was originally published on Medium by Malte Ubl, Tech Lead for the AMP Project.

But what about the ads?

Growing your mobile visitors with AMP

Speed matters – and not just when you are chasing a rare Pokémon in the wild. Research has shown that 40% of users abandon a site that takes more than 3 seconds to load.

We launched AMP to make the experience of loading screens obsolete. And users are already noticing. Today, The Washington Post is sharing with the AMP community some promising user engagement and retention stats: since The Washington Post adopted AMP, they observed an 88% decrease in article loading time, resulting in a 23% increase in returning users from mobile search.

Click here to read the full case study

As more sites implementing AMP share information about their experience, we’ll make sure to update you through this blog and @amphtml.

Posted by Adam Greenberg, AMP Partnerships

Growing your mobile visitors with AMP