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
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.
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
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.
Accelerated Mobile Pages Project 