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 <amp-live-list>, 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 <amp-live-list> is displayed on the client, <amp-live-list> 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 <amp-live-list>, all you have to do is:
While the component is in beta, opt into the experiment by entering
In the HTML for an AMP page, wrap any live-updating content in <amp-live-list> and its children, ensure that each element has the required attributes and structure, and publish the page.
Whenever new information comes in, update the HTML for <amp-live-list> with new entries or changes to older entries, and re-publish the page.
That’s it! The child elements of <amp-live-list> will be dynamically updated as new content comes in.
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 <amp-live-list> 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 <amp-live-list>, the sooner we can polish it up and release it to production for use in your AMP pages.
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.
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.
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.
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.
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
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.
Going deeper: A restricted subset of AMP
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.
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
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.
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.
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.
As more sites implementing AMP share information about their experience, we’ll make sure to update you through this blog and @amphtml.