Introducing Bing AMP viewer and Bing AMP cache

The below was originally posted on Microsoft Bing’s blog by Fabrice Canel, Principal Program Manager, Microsoft Bing

In 2016, Bing joined the Accelerated Mobile Pages (AMP for short) open-source effort to help you “find” and “do” searches faster, regardless of where you are and on any device when you are looking for information. Today, we are pleased to announce the release of Bing AMP viewer and Bing AMP Cache enabling AMP-enabled web pages to work directly from Bing’s mobile search results allowing Bing to provide faster mobile experiences to Bing users.

On Monday, the 17th we started the first phase of the global roll out of this AMP viewer and AMP carrousel in the United States for the news carrousel. We will continue the phased roll out to more web sites, more countries and regions and other links in the search results pages. Also, if you are in the United States, try it out on your mobile device by navigating to and search for news related queries and tapping the search results labelled with the AMP icon: .



Advice for AMP webmasters, AMP advertisers

The AMP protocol offers the ability to cache and serve cached copied AMP content that is published on the web, providing faster user experiences on Bing. In order to enable your AMP published content within Bing, you need to allow the Bingbot (our crawler) to fetch AMP content and allow cross-origin resource sharing (CORS) for domain. Most AMP enabled sites and advertisers have already authorized the CORS sharing for the domain, but now need to also to the allowed list.

Posted by Fabrice Canel, Principal Program Manager, Microsoft Bing

Introducing Bing AMP viewer and Bing AMP cache

An open governance model for the AMP Project

Over the last 2 years AMP has grown from a tiny open source project with just 2 contributors to a much larger one with over 700 folks contributing over 10,000 commits running on many millions of websites. When choosing a governance model (a system that describes how decisions are made) for AMP,  we initially focused on agility. AMP has always been powered by the voices and feedback of the developers and organizations that use it; however, governance was centered around the tech lead (which is me, the author of this post 🤣), who ultimately decided what got executed and how.

While this works great for smaller projects, we’ve found that it doesn’t scale to the size of the AMP Project today. Instead we want to move to a model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users. The change we are proposing is based on months of research, through which we’ve decided to follow the lead of the Node.js project and move to a consensus-seeking governance model.

AMP received contributions from 710 contributors overall, 22% from Google employees, 78% from other companies such as Twitter, Pinterest, Yahoo, and eBay. In the last 30 days alone over 350 contributions landed in AMP!

When creating this proposal for a new governance model for AMP the AMP team had a few goals in mind, including:

  • Encourage a wider variety of voices at all levels of contribution, including code contributions, setting the future direction of AMP and deciding which features and bug fixes should be worked on.  This also means ensuring that the voices of those who do not contribute with code, but are nonetheless impacted by AMP, get heard.
  • Make it more clear how an individual and a company can have a voice in AMP, from approving code changes to setting AMP’s technical and product roadmap.
  • Avoid slowing down day-to-day work on AMP due to the governance model.  The net effect of changes to the way people work on AMP should be neutral to positive in terms of productivity.
  • Learn from what’s worked and what hasn’t worked for other open source projects.  To this end the AMP team talked to people from projects such as Node.js and Kubernetes, looked at governance philosophies from places like the JS Foundation and reviewed a wide variety of other open source and web standards governance documents.

The proposal has full details but some of the significant changes proposed in the new model are:

  • The power to make significant decisions in the AMP Project will move from a single Tech Lead to a Technical Steering Committee (TSC) which includes representatives from companies that have committed resources to building AMP, with the end goal of not having any company sit on more than a third of the seats.
  • An Advisory Committee with representation from many of AMP’s constituencies will advise the TSC.
  • Working Groups with ownership over certain aspects of AMP (such as the UI, infrastructure and documentation) will replace the informal teams that exist today.  These Working Groups will have a clear mechanism for input and a well-defined decision making process.

One of our first tasks in working towards the new system is to complete the initial membership of AMP’s governance groups. If you are interested in being involved in any of these governance groups please let us know. This is real work, and we want to pay for it if it isn’t covered by your day job! If you need financial support, please let us know in the form. One area that we are particularly interested in is representation from folks with experience in consumer rights and protection. Meanwhile we’re excited to announce that we’ve talked to a few folks up front and they agreed to join the Advisory Committee including representatives from publishers (El País, Washington Post and Terra), e-commerce sites (AliExpress and eBay) and platforms (Cloudflare and Automattic) as well as advocates for an open web (Léonie Watson of The Paciello Group, Nicole Sullivan of Google/Chrome, and Terence Eden).

Additionally, we’re exploring moving AMP to a foundation in the future, and we’ll seek the input of the TSC, the AC, and the community over the coming months. We see the governance changes as a first step in that direction.

We’re looking forward to working with the rest of the AMP community to refine the governance proposal, including at next week’s AMP Contributor Summit.  We encourage you to review and comment on the proposal and attend the design review that has been scheduled to discuss the proposal.  The review period for the proposal will end on October 25, 2018 with a goal of implementing the new governance model shortly thereafter.

We’re excited to see the AMP community take this next step, and hope you will join us in making the web a better place for users and developers alike.

Posted by Malte Ubl, Tech Lead for the AMP Project at Google

An open governance model for the AMP Project

Measuring user journeys across the AMP Cache and your website

“If you can’t measure it, you can’t manage it.” — Peter Drucker

As users demand better privacy controls, browser vendors have started responding with defaults that partition cookies. This means traditional approaches of relying on third-party cookies for measurement won’t work going forward.

AMP pages are often served from an AMP Cache and the ability to maintain a session by using a third-party cookie allows publishers to remember user settings and preferences even when users move between the AMP cache domain and the publisher’s domain.

AMP Linker

AMP Linker is a new feature in AMP that helps keep user session in sync. It works by decorating outgoing links from AMP cache with params such as AMP Client ID in a URL parameter. On the receiving side, your analytics provider consumes the parameter and writes it down as a first-party cookie.

The decorated link will look something like*19eaxqc*bar*V2dj…eHZKYg


Enable AMP Linker

AMP Linker works by including a config for your analytics provider. For instance, if you’re using Google Analytics you’d include something as follows:

<amp-analytics type=”googleanalytics”>
 <script type=”application/json”>
     “linkers”: {
       ”enabled”: true

If you already use the Google AMP Client ID API with Google Analytics, no additional tagging is required to take advantage of AMP Linker capability.

If you are an analytics provider, we welcome you to reach out to us to take advantage of AMP Linker.

Looking ahead

We’re hard at work to support non-traditional, yet important, user journeys where a user goes from non-AMP pages to AMP pages. Keep an eye out on our repo on Github for updates regarding those.

Happy measuring!

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

Measuring user journeys across the AMP Cache and your website

Compare images on AMP pages with amp-image-slider

Earlier this month we announced the experimental release of <amp-image-slider>, an overlaid slider that allows you to compare 2 images that are superimposed on each other. We are now excited to fully launch this component in production.


The benefits of using include:

  • An interoperable interaction model across all devices and platforms.
  • Built-in accessibility – like all of our components, we have designed the component with accessibility in mind. This means we have ensured the component is accessible to both keyboard navigation and screen readers.
  • Ability to customize the component to your site branding by modifying the hint arrows.
  • Ability to customize the interaction model of the component by setting the step size for keyboard navigation, adding labels on the images being compared, etc.

amp-image-slider (labels).gif

Check out the sample on
AMP by Example and the documentation to learn more, and please file any feedback you have as well!

Posted by Naina Raisinghani, AMP Engineer at Google

Compare images on AMP pages with amp-image-slider

Ensure Ad Density is equal on AMP & non-AMP pages

Editor’s note: The following was originally posted on Medium by Vamsee Jasti, AMP Product Manager at Google. This post is part of a larger AMP monetization series.

Avoid common pitfalls to ensure total area of ads is the same

Ad density doesn’t have to be as high as it is at Times Square

This is an easy optimization, but is important because it’s one of the most common mistakes and is easy to remedy.

A reasonable ad density strategy is to follow the guidance from the Coalition of Better Ads. It says that the total height of the ads on the page / total height of the content on the page should be < 30%. This is of course the worst case scenario and often publishers have percentages lower than this.

During my publisher interviews, three common misconceptions came up when inquiring why some didn’t have the same ad density on both AMP and non-AMP pages:

1. “I didn’t realize I needed to manage ad density”

When probing further, the AMP model was being confused with Facebook Instant Articles’ approach to ad density where there is an automated ad insertion offering. AMP doesn’t directly offer publishers a way to automatically manage ad density but it makes APIs available that allow auto-ad insertion to the 100+ ad networks natively integrated in AMP. Individual ad networks can choose to take advantage of those APIs, similar to howAdSense does. For most ad networks, including DoubleClick for Publishers (DFP), such auto placement is not available and publishers must manage ad density themselves.

2. “I thought there were restrictions on the number of ads I could place”

Turns out, they were mixing AMP up with FIA’s approach, where they have apolicy to replace manually placed ads if the ad density is greater than 20%. AMP has no such restrictions. AMP delegates the responsibility to the publisher and the individual ad network they choose in order to eliminate any AMP-specific idiosyncrasies related to ad density management.

3. “We didn’t optimize our AMP pages after the initial AMP launch 3 years ago”

A lot can change over 3 years and some publishers had undergone architectural changes but their engineering teams may have forgotten to include AMP pages in the re-architecture. It’s important to keep both sets of pages at parity not only to earn the same revenue from your AMP pages but also helps you understand how your AMP pages are performing.

A specific area to call out is to ensure parity on recirculation promotions that allow users to consume related content. Not having these on your AMP pages may have a negative impact on your bottom line because anecdotally these lead to 1.2 or 1.3 times session lengths. AMP supports various 3rd party recirculation providers too.

In summary, regardless of what strategy you use on your non-AMP pages, ensure you translate that strategy over to your AMP pages. There are no restrictions in AMP that would make a publisher have fewer ads on AMP pages than on non-AMP Pages.

Ensure Ad Density is equal on AMP & non-AMP pages

Are you leaving revenue on the table with AMP?

Editor’s note: The following was originally posted on Medium by Vamsee Jasti, AMP Product Manager at Google. Find topic specific posts from this series below:

I’m a product manager working on AMP and we strive to make advertising better on the web while helping publishers thrive. I’m writing this to give you some background on design choices we made for advertising in AMP and then follow up every week with specific optimization recommendations to help you take maximum advantage of AMP pages.

Make the most of your AMP page revenue by optimizing them

Bottom line first: If you are publishing AMP pages, please at least make sure they are monetizing well. It’s possible, if one invests in them.

When AMP launched, it was important for us to help publishers make revenue from your AMP pages just the way you did from your non-AMP because ads are still a big source of revenue for many publishers. After numerous interviews with publishers, I’ve seen some not take full advantage of their AMP pages and therefore leaving a lot of revenue on the table.


We worked with a number of publishers to get feedback around AMP monetization and used to hear that there were many ad features that needed support in AMP but that feedback volume has decreased after we launched a number of features over the last year. There is always more work to be done but since AMP’s launch, we’ve launched a number of features and closed almost all gaps now.

There are publishers out there who have not only reached revenue parity but exceeded revenue from their AMP pages compared to their non-AMP. For some publishers who receive close to 50% of their traffic to their AMP pages, this can be a million plus dollars per year!


If you are a publisher who is in the business of developing an audience (visitors who choose to come to your site often) and not traffic (visitors who visit based on one-off click baits or by purchasing traffic on platforms) you probably already consciously balance a tradeoff. The tradeoff between the user experience of the site to the revenue you generate from ads. To take an extreme example: one could easily show 3 successive pop-up ads before the article which would generate a lot of revenue but it would also either lead users to immediately leave the site or negatively associate the publisher brand in a way the visitor thinks twice before going to the site.

Principles behind advertising in AMP

When it comes to this tradeoff, with AMP, we took a balanced stance to prioritize user experience over anything else but re-imagined how ads could still earn very good revenue with features that are hard to implement on non-AMP pages for legacy reasons.

Here are a few of them:

1. Get ads out of the critical path of rendering the page

Unlike regular pages, AMP pages make the ad requests on the page as early as possible in the lifecycle of the ad. This allows us to parallelize rendering the page, while also letting the ad server run its auction to pick the best ad. Chances are, by the time the ad comes back, the page has already finished loading and therefore the ad can also immediately render which leads to ads having better viewability and click through rate. We’ve gathered data that shows that AMP performs really well on these measures. A win-win for both publishers and advertisers by simply orchestrating the ad request sequence. We call this “Fast Fetch” and you can read all about the improvements here. Following this change we have had great results with users seeing a lot fewer blank rectangles.

Fast Fetch vs Delayed Delayed Fetch Ad Requests

Contrast this to delayed fetch, where the ad request isn’t made until the browser encounters the ad tags, therefore delaying making the ad request and subsequent rendering.

2. Don’t allow user visible reflow but support multi-size ads

How often do you visit a site and start reading content and out of nowhere, an ad appears and pushes the content down, causing your thumb to do a micro-dance so you can continue reading as it loads? We think this experience is clearly bad for the user which is why AMP made an early tradeoff to ensure that doesn’t happen. Therefore, every ad must have a predetermined primary size, so AMP can reserve the space for the ad but continue to render content all around without ever reflowing content.

AMP reserves a primary ad size so there is never user visible reflow

But we know that multi-size ads lead to better monetization since it makes the ad auction demand pool larger. AMP introduced a way for publishers to define a primary size and also pass along secondary sizes which allowed resizing the ad to the returned size as long as the ad was below the viewport or was smaller than the primary size, if in the current viewport. Publisher feedback has shown that this was a healthy tradeoff giving publishers > 90% chance of serving the ad size that earns them the most revenue. I’ll go into more detail in a future post, but here is the launch blog post.

3. Prefer ad formats that users can easily dismiss or scroll past

Let’s admit it. A majority of users visit your site for content, not ads. So some design choices were made in AMP to never show an ad that would “cover” content. Which means no pop-ups (interstitials) that cover content. Interestingly, the industry as a whole is rejecting such ad formats. Instead we supported all ads within fixed layouts, including all Rich Media Ads.

AMP prefers ads that can be easily dismissed by users

In addition, AMP launched some native ad formats like sticky ads and flying carpet ads. We plan to support even more richer formats that publishers tell us they’re interested in while ensuring a great user experience. With any ad format, users should be able to tap the dedicated close button on the ad or could simply scrolling away.

OK, show me the money?

Don’t get me wrong, nothing is as easy as flipping a switch. You constantly optimize, try new things out, experiment and settle with an ad setup that gives you the most revenue while adhering to good UX principles.

But the good news is that such optimizations are fairly straight forward in AMP. Plus, you only need to do a handful of things to ensure that your AMP pages generate maximum revenue.

Over the next few weeks, I’ll dive into each of these topics:

  1. Ad Density
  2. Prefer Viewability over Views
  3. Multi-size ads & fluid
  4. Traffic your direct sold ads (formats & single request architecture)
  5. Header Bidding & AMP
  6. Video monetization using AMP IMA Video
  7. Auto Ad Refresh
  8. The future with AMPHTML ads
Make a change & earn the revenue from AMP

With AMP, we believe in providing you with flexibility in implementing where you source your ads from and what vendors to work with. You don’t lose a slice of your rev share just for using AMP. There are over 100 ad networks that are natively integrated with AMP pages and many more supported via header bidding (using AMP RTC) and server side exchanges.

The AMP team strongly believes in the open web and strive to help publishers build a sustainable business on it whether it be paywalls or advertising.

Stay tuned for more in the coming weeks and we look forward to your feedback on this series or anything else about AMP. In case you can’t wait to get started, check out the summary of monetization best practices and implement away!

Are you leaving revenue on the table with AMP?

WorkerDOM: Concurrency for JavaScript programming with the DOM

We are happy to announce the alpha release of WorkerDOM – a JavaScript library that makes the Document Object Model (DOM) available to Web Workers. This allows web developers to take advantage of pervasive multi-core processor architectures when programming their web pages to make them more performant. While the WorkerDOM library is designed for general web programming, we plan to use it in the AMP Project as well, which we will detail more below.

The underlying Web Worker API has been available to web developers for almost a decade, but it hasn’t seen widespread adoption. One of the reasons was that the primary API for manipulating web pages, the DOM, was not available inside of workers. WorkerDOM changes this, thereby enabling developers to more easily port their existing applications. We hope that this will spur renewed interest in multi-threaded programming on the web, and lead to much better experiences for users down the road.

Our research has shown that single-core CPU performance for low-cost devices has not significantly increased over the last years. As a result, from a single-core point of view, mobile devices have gotten cheaper but not faster. There is significant opportunity to take advantage of the extra cores that even the least expensive CPUs provide that aren’t available to JavaScript programming by default. To make web performance truly competitive with that of native platforms, we should try to unlock this extra bit of performance to provide better and more modern experiences across the whole range of devices people use.

Screen Shot 2018-08-21 at 10.45.37 AM
Not all mobile devices are created equal.

WorkerDOM aims to provide a full representation of the DOM inside of Web Workers. In the ideal case this means that scripts can be used unchanged inside of the worker environment. At the heart of the library is an efficient transport mechanism written in TypeScript. It hydrates server rendered DOM and then proxies mutations as an application makes changes to the page, such as reacting to user actions or running animations. For more details about the inner workings of the WorkerDOM library and possible use cases, please check out the slides from our presentation at JSConf US 2018.

As announced at the AMP Conf 2018, the AMP Project is working on a long-term effort to make JavaScript programming available to AMP page authors. The WorkerDOM library is central to this initiative and we’re excited to incorporate it into AMP later this year. WorkerDOM is compatible with frameworks such as React, Preact, and Svelte — and more are on the roadmap. We’re super excited to see all of these frameworks used in creating AMP pages in the future!

Today’s release is an alpha release. WorkerDOM is ready for experimentation but not yet ready for widespread production use. We’d love to collaborate with framework and tool authors to ensure compatibility and great developer experience when using WorkerDOM in as many places and contexts as possible!

Kristofer Baxter, Software Engineer at Google

WorkerDOM: Concurrency for JavaScript programming with the DOM