Behind the Scenes: Deploying the AMP Runtime

Developer Experience

One of the main benefits of using AMP is its evergreen release. Today, web developers and engineering teams can get the best of what AMP has to offer every week without being burdened by dependency management. 

Over the past few months, the Infrastructure Working Group has been working hard to improve the way AMP releases its runtime and components. The improvements are based on the following feedback:

  • Some development teams prefer a slower release cadence so they don’t have to run Quality Assurance (QA) for their website every week.
  • Existing documentation for AMP releases can sometimes be incomplete or confusing.
  • It’s essential to be able to detect potentially breaking changes before they reach the majority of end-users.
  • Some partners would like to be able to self-host the AMP runtime and components during development instead of having to fetch them from

The goal of this blog post is to help the reader understand how AMP releases work today, and to learn about upcoming improvements (like updated release channel names, the LTS and Nightly channels, and the ability to self-host AMP on origin URLs).

Understanding AMP Releases

A new version of the AMP runtime is released each week. In order to create confidence in the fact that publishers’ websites will look and behave the same, releases are provided via multiple channels. The main release channels are called Stable, Beta, and Experimental. They serve different purposes, and are seen by different population sizes. In addition, we’re introducing two more channels called LTS and Nightly to further aid in testing and maintenance. Here is a brief description of each channel.  

Stable Channel

This is the main production-ready release channel for the AMP runtime, and is used by the vast majority of AMP documents. When a change is submitted to the AMP codebase, it goes through multiple layers of testing and verification via other channels before becoming part of the stable channel.

Beta Channel

The beta channel is an accurate representation of the upcoming stable channel release. Developers and QA teams may opt in to the beta channel in order to verify their websites against the latest changes to the AMP runtime. This can be done by opening the AMP experiments page in a browser and activating the “AMP Beta Channel”.

Note: Opting in to the beta channel will only affect the version of the AMP JS libraries used in your browser. There is no way to force visitors to your website to receive the beta channel version of AMP.

The beta channel may be less reliable than the stable channel, and may contain features not yet available to all users. It is intended for:

  • Trying out a new AMP feature that will be released the following week.
  • Performing QA to verify that a website is compatible with the next version of AMP.

Experimental Channel

Some new AMP features can take multiple weeks to develop and test. As a result, they are hidden behind experimental flags that are turned off in the beta and stable channels. The experimental channel provides developers and QA teams with a way to try out and test new features. This can be done by opening the AMP experiments page in a browser and activating the “AMP Experimental Channel”.

Note: Opting in to the experimental channel will only affect the version of the AMP JS libraries used in your browser. There is no way to force visitors to your website to receive the experimental channel version of AMP.

The difference between the experimental and beta channels is the fact that some features that are in development may be available in experimental, but turned off in beta. If a feature is considered ready for use, its flag is turned on, making it visible in the beta channel, and eventually, the stable channel. Depending on the feature, this could take days, weeks, or even months.

Long Term Stable (LTS) Channel

A recurring request from developer teams has been for an AMP release channel with longer intervals between versions in order to allow for a longer QA cycle than the current weekly cycle.

The newly created Long Term Stable (LTS) release channel solves this problem. Approximately monthly, a recent stable channel release is promoted to the LTS channel.

It’s important to note that the LTS channel is not recommended for all AMP publishers. It is provided for those who wish to test their websites less frequently, and are okay with waiting a few weeks before using new features. Publishers may opt to use the LTS channel for specific pages on their website. Webpages using the LTS channel will get the same cache benefits as with the stable channel.

Unlike the beta and experimental channels which individuals can opt in to by setting a browser cookie, the LTS channel is served to all users of a webpage when the publisher opts to use it for that page.
A new LTS version is made available on the second Monday of each month by promoting the previous week’s stable channel release. The schedule for the LTS channel can be found here.

Using the LTS Channel for a Webpage:

Here’s an example of a webpage that uses the stable channel:

<script async src=""></script>

To use the LTS channel instead, simply change the “src” attribute for the runtime and extension scripts as follows, by adding “lts/” to the URL:

<script async src=""></script>

Note: You should ensure that the AMP runtime and extension scripts you are using are on the same channel to make sure your AMP document is valid. For example, using v0.js from the LTS channel and amp-carousel-0.1.js from the stable channel will result in a validation error.

Nightly Channel

In order to increase confidence in the quality of upcoming AMP releases, we will soon automatically generate nightly builds of the AMP runtime, and make them available via a new Nightly channel. This channel will help reduce error rates, improve runtime performance, and ensure overall code quality. Code from the nightly channel will eventually make it into the beta / experimental, stable, and LTS channels. Once it is introduced, developers will be able to opt in to the Nightly channel in the same way that they can opt in to experimental or beta, as described above.

Note: We do not encourage developers to opt in to the nightly channel unless they wish to test changes daily, as it is less stable than the beta, experimental, and stable channels.

Release Schedule

The section above went over all the existing and upcoming release channels. Let us now follow the journey taken by a piece of code from when it is submitted to the open source repository via a pull request, to when it makes its way through the various release channels.

Suppose a piece of code is merged to the open source repository on the 8th of a given month (N). Since this happens to be a weekday, the following nightly build (the 9th) will include the code. After a few days of testing, on Tuesday the following week (the 16th), users can see the code by opting in to the beta or experimental channels. Assuming no issues are discovered, the code will make it to the stable channel the following Tuesday (the 23rd). Finally, on the second Monday of the following month (the 16th of month N+1), the same stable channel release will become the new LTS channel release.

You can read more about AMP’s release channels and schedule at the project’s release schedule page. You can also visualize the process by which new code is merged into the amphtml GitHub repository progresses through time to reach publishers, developers, and end-users.

A New Way to Self-host the AMP Runtime

We are currently working on making it possible for website owners to self-host the AMP runtime, without breaking AMP validity. The benefits are:

  • Independence: The AMP runtime and components no longer need to be loaded from for AMP pages served from an origin URL.
  • Control: Websites can align the roll-out of a new AMP version with their own QA. They can also rollback to a different version of the AMP runtime whenever the need arises.
  • Performance: Faster page load and TTI by avoiding an additional HTTPs connection.

The goal is to allow publishers to link to a self-hosted version of the AMP runtime without breaking AMP validity. This means the following will be valid AMP:

<!DOCTYPE html><html amp transformed="self;v=1">
  <script async src=""></script>
   async custom-element="amp-bind"

Note: In order to preserve user privacy, AMP Caches will not support runtime self-hosting and instead will rewrite links to the cache hosted scripts. 

The plan is to launch AMP runtime self-hosting later this year and you can follow the implementation via the intent-to-implement and the design doc

* * *

With all these changes, we hope AMP releases are easier to understand, adopt, test, and deploy. Our thanks go out to you, 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 Naina Raisinghani and Raghu Simha, AMP Project

Helping to fund our open-source dependencies


As has now become a yearly custom, we want to update you all on our effort to help sustainable development open-source projects that AMP depends on.

It is increasingly clear that relying on people’s volunteered free time to drive mission critical open source software is not a sustainable mode of operation. As a community we need to find new ways to fund the valuable work on such projects. We strive to provide at least some financial support to projects that we directly depend on and that are accepting support.

Total funding: $117,100 (2019 $58,700)

The projects we supported are:

We’re super glad we’ve been able to support these amazing projects and are looking forward to doing even more in 2020!

Posted by Malte Ubl, Member of the AMP Project Technical Steering Committee

Cookie classification on AMP

Web Standards

Posted by Katharina Familia Almonte, Global Product Lead at Google on the AMP Project

Last year, Chrome announced its plans to introduce a cookie classification scheme as part of its ongoing effort to improve privacy and security across the web, which is expected to take effect with Chrome 80 in February 2020. Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft has announced plans to begin implementing the model starting as an experiment as soon as Microsoft Edge 80.

The AMP team is committed to protecting user privacy and this blogpost will explain how you can support greater transparency and user choice with the upcoming browser changes, while also maintaining a good user experience with AMP. With Chrome 80 expected to launch in February, this blogpost will focus on Chrome’s changes specifically.

Chrome’s new cookie settings explained

Chrome’s new secure-by-default model assumes that all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access, and an additional Secure attribute so cross-site cookies can only be accessed over HTTPS connections. Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. For more detail on the new model, read this developer blog post.

Who’s affected

If your site needs to access your own first party cookies on AMP pages rendered in the AMP Cache, we recommend assessing carefully whether the upcoming browser changes will impact your user experience. This could be the case, for instance, when users transition from the AMP cache to the origin domain and a paywall, login state, measurement or shopping cart functionality relies on first party cookie access. There are two different solutions you could employ, but which one is best for your site will depend on your specific use cases and can change over time.  

Designating cookies for cross-site access

One solution for AMP publishers affected by Chrome’s cookie classification changes, is to set your first party cookies on AMP pages to SameSite=None; Secure. This will designate the first party cookies  for cross-site access and avoid disruptions in user experience:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

The benefit of this approach is that it is the easier one to implement, but if browsers proceed to offer users fine-grained controls to manage cookies accessed by a single site separately from cookies accessed across multiple sites, there is a higher risk that users will clear your first party cookies on cached AMP pages since they will be marked for cross-site access.

Signed Exchange offers help

Alternatively, publishers can use Signed Exchange to achieve a state where first party cookies are treated as such on AMP pages rendered in the AMP Cache. Signed Exchange is an emerging technology that can be used to attribute the page’s URL to the original publisher domain, even when the page is delivered via the AMP cache with all of the loading speed benefits it provides (see blog post and guide). The benefit of Signed Exchange here is that when browsers start preventing cookies from external access unless they are specified otherwise, Signed Exchange will ensure that your first party cookies don’t require designation on pages rendered in the AMP Cache. But Signed Exchange does not currently address all use cases as it is not supported in the Top stories carousel at the time of writing.


In summary, Chrome is planning to introduce its new SameSite=None; Secure cookie settings in February. To ensure an optimal user experience on pages in the AMP cache that need to access first party cookies, we recommend publishers designate cookies for cross-site access via these new settings or implement Signed Exchange. We hope this blog post helps you maintain a good user experience while also supporting the path to greater privacy controls for users, as browsers start adopting the new cookie classification model. For more details on how to use and test Chrome’s SameSite cookies check out the guide on and the tips in the Chromium SameSite Updates.

CCPA support in AMP

Web Standards

Posted by Jeffrey Jose, Product Manager at Google on the AMP Project

The California Consumer Privacy Act (CCPA) is a new data privacy law that establishes various rights for California state residents. The law applies to companies that do business in California and meet one of several criteria related to revenue, data processing, and other factors. 

Updates to the AMP consent framework

Based on the feedback we heard from publishers, we’ve updated the AMP consent framework to obtain the consent publishers might deem necessary for CCPA compliance. With these new updates, publishers can include multiple consent prompts and trigger the right prompt based on the location of the user.

Consent across multiple surfaces

Publishers who wish to keep user consent in sync between multiple surfaces can store the user’s consent on the server-side and expose the information to <amp-consent> via the checkConsentHref attribute. You can configure AMP to check your endpoint first and the response determines whether a user-consent prompt is displayed or not. Additionally, the previously obtained user consent can be passed from the server to the ads and analytics vendors configured on the page.

Support in AMP Stories

For AMP Stories, publishers can create links to their CCPA opt-out page within a story to collect user consent. 

We’ve also updated our reference docs and with sample codes to illustrate sample scenarios.

Looking ahead

To make development easier, we plan to extend <amp-geo> in the future by providing US state level detections of users. As always, we invite you to submit new ideas by filing an issue. If you’re a vendor who wants to customize how your AMP extensions behave based on user controls, please get started by following our contribution guidelines.

AMP 2019 Decoded: Thank You for an Incredible Year


2019 was a big hit for AMP. We continued to grow our community and create excellent experiences across websites, email, stories and ads. So let’s flashback to the beginning of this year and recap all the milestones we accomplished together.  Watch the video and read below:

Next.js for AMP 

Building AMP pages through React server-side rendering has gained enough momentum for us to realize we needed to add to our capabilities to support this use-case. That’s why we integrated with Next.js, one of the most popular frameworks for React. Fun fact: is built entirely with AMP!


The game-changer <amp-script> finally hit your screens this year. This highly anticipated component enables you to add custom JavaScript to your AMP pages, share code across AMP and non-AMP pages, and build things that were not possible before.

OpenJS foundation welcomes AMP 

We revealed what’s next for our open governance model by announcing our decision to join the OpenJS Foundation. Its mission aligns with ours, and it’ll magnify diverse voices in tech and support our efforts to create a fairer web. 

AMP in your inbox 

Gmail launched support for AMP for email, bringing our user-first experience to an inbox near you. Email senders can now create frictionless experiences and interactive content to boost engagement. The AMP for email spec also has engagement from other major email providers like Outlook and Yahoo Mail, and we are looking forward to reshaping the email ecosystem together. 

The new component is also available on, and early adopters are already celebrating great results. OYO, India’s largest hospitality company, saw a 60% uplift in conversions when testing AMP for email. 

Arigato for making AMP Conf a success  

Our team met nearly 500 of you in Tokyo at our third annual #AMPConf. In addition to product announcements, we also launched a completely redesigned, one website for all of our code samples, templates, and documentation. AMPConf2020 is already in the making, so stay tuned to hear where we will be taking the event next.

AMP Contributors Summit in the Big Apple 

In early October we caught up with around a hundred contributors in New York at the annual #AMPCS2019 to discuss new features for AMP. It wasn’t just talk, we hosted breakout sessions where we worked together to improve our projects, and knocked some AMP socks off in the process. 

A strong community

Nearly 1,000 people have contributed code to AMP and are helping us design a faster, better web for all. This year alone, 341 contributors made over 18,300 contributions across all AMP project repositories. 

The People Behind the Code

The community plays a massive role in making AMP great; it’s where we share what we know and learn what we don’t. So we launched the ‘People Behind the Code‘ series to understand how community members use AMP in real life to make a difference. 

19 new Roadshows under our belt 

AMP hit the road 19 times this year, taking our Roadshows around the globe. From Johannesburg to Seoul, 1,600 of you came out to see what AMP is all about. 

The Roadshows are designed to help developers build full-fledged AMP websites with confidence. So we deep-dive into the key four pillars: design, interactivity, DevOps and monetization, to make sure you have everything you need to excel. 

If you want to see where we will be going in 2020, head over to our AMP Roadshow page to find out. Can’t see your city on the list? Let us know, we’re always looking for new places to visit, or host your own event. We’ll provide you with all the material – all you need to do is to show up!

2020 vision 

It’s been a remarkable year. Thank you for your creativity and commitment to creating a faster, user-first web for all. We’re excited to see what’s next for AMP, and look forward to continuing our work together in the new year. To stay in the loop about all of AMP’s projects and see our 2020 vision, sign up for our newsletter. 

Posted by Alex Durán, AMP Project Marketing at Google

Our 2019 Contributions to Web Platform Interoperability


Editor’s Note: the following post was written by Frédéric Wang, Partner at Igalia

For the third year in a row, the AMP Project has worked with Igalia to address bug reports and enhancement requests from the Web community. Typical tasks include bug triaging, debugging and analysis, writing tests, landing patches, and discussions with the different actors of the Web platform. This has not only been instrumental to significantly speed up the goals of the AMP project, but has also been generally beneficial to all the developers and users of the Web platform.

This blog post describes our activities for this year, focusing on WebKit/iOS bugs and features. However, our Web platform interoperability effort occasionally extends to other browser communities and standardization groups as well.

Resize Observer

Intersection Observer shipped in iOS 12.2 thanks to Google Engineer Ali Juma. This is a new JavaScript API to asynchronously watch changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.

Resize Observer is a similar API  which we implemented earlier this year under a preference flag. This JavaScript API allows Web developers to asynchronously observe when an element is resized, regardless of why. It is available in iOS 13 beta and the corresponding preference flag has been turned on by default in trunk, so we expect this feature to be available in the iOS 13 release. (Update 01/28/2020: ResizeObserver is now part of Safari Technology Preview)


Apple took over the task we started last year to make <iframe> elements scrollable and this behavior is now enabled by default in the latest iOS 13 version. Other bug fixes involving scrollable elements landed for scroll-snap-align, scrollability after resize find-in-page indicator after scroll as well as for various iOS 13 regressions related to scroll flickering and jittering.

Enhancements have been implemented for the ScrollIntoViewOptions parameter of scroll APIs. Support for logical scroll alignment is shipped in iOS 13. We also continued our efforts to support the scroll-behavior IDL parameter and CSS property and we expect to complete this in the next semester. While working on this, we also detected and fixed Chrome bugs related to the scrollIntoView() method, including cases when a scrollbar is present or when the scroller uses a non-default writing mode.

An old browser interoperability issue for users relates to inconsistent values of scrollLeft, scrollTop and similar APIs and one of our important achievements has been to ensure more reliable and standard behavior happens when setting or getting scroll coordinates. We introduced an option to make Chrome use standard values in non-default writing modes and plan to ship it, after ensuring that it won’t cause serious breakage. Similarly, Apple decided to enable our 2018 changes for the viewport scroller on all WebKit ports.

Besides usual bug fixes, we began implementing other interesting scrolling features, including overscroll customization and overscroll-behavior which are powerful APIs for web developers to control what happens when a scroller reaches its boundaries. We expect more progress on this next year.

Resource Loading

Another exciting goal is to give more power to Web authors to control loading behavior. In particular, this allows the ability to control privacy and optimize page layout.

The referrerpolicy attribute has been implemented to specify how much referrer information should be included within the requests associated to an HTML element loading resources. This is only implemented for the <iframe> and <script> elements and is available in iOS 13 under an experimental feature flag. We will continue to talk to Apple to see when this can be enabled by default or implemented for other elements.

The imagesrcset and imagesizes attributes on <link rel=preload> have also been implemented and are available in iOS 13 under an experimental feature flag. These attributes give the possibility to preload a responsive image represented by an <img> element with relevant sizes and srcset attributes and optimize the selection of the appropriate size for the user device.

We also started to submit patches to support the lazyload attribute on the <img> and <iframe> elements. These attributes enable Web authors to indicate whether it is a good idea to lazily load the element content (e.g. if they are not visible in the viewport until the user scrolls to them) or if their content should instead be loaded right away. These hints are very helpful for browsers to optimize loading of resources.

Finally, we made an experimental support for the intrinsic size attribute in WebKit. This proposal is intended to help browsers to determine aspect ratio or size of an image before its content is actually loaded, in order to avoid extra post-load reflow. This proposal has been superseded by a pure CSS-based approach addressing the same use case. Our experiment was useful for discussions among browser vendors and within the CSS WG and we plan to rewrite our patch to instead implement the CSS-based approach in WebKit.


Collaboration between the AMP project and Igalia to advance the state of the Web Platform has been very successful. There are several pending tasks and new ideas to work on so we look forward to continuing with this effort next year!

From Static to Interactive: Adobe Campaign Brings Email to Life with AMP for Email


Adobe drives innovation as one of the firsts to deliver this modern app functionality from Google.

Editor’s Note: the following guest post was written by Sunil Menon and was originally featured on the Adobe Blog

Email continues to play a major role both in our professional and personal lives. In fact, according to Adobe’s annual Consumer Email Survey, Americans spend more than five hours a day checking their emails. With consumers spending so much time in their inbox, email has become an essential channel for brands to engage with their customers. Our survey also revealed that 60% of consumers prefer to receive brand offers via email, yet consumers only find a quarter of the emails they receive interesting enough to open.  

If email content is static, it can become out-of-date almost as soon as it’s sent. Plus, email often requires the consumer to take action forcing them to exit the email or opening a browser window, making the experience feel more fragmented or transactional. How can brands take better advantage of the time consumers spend in their inboxes to deliver more personalized experiences and drive higher engagement? The answer lies in creating emails that are both interactive, authentic and informative.  

To help brands stand out among the more than 290 billion emails that are sent every day and to further demonstrate its commitment to innovation, Adobe Campaign, part of Adobe Experience Cloud, is announcing compatibility with AMP for Email, supported by Gmail and other mail clients. Available to Adobe Campaign customers now, this innovative modern app functionality for email allows senders to include AMP components inside rich, engaging emails sent from Adobe Campaign Classic. Adobe Campaign is among the first group of email marketing solutions to be compatible with AMP for Email.

By leveraging AMP for Email within Adobe Campaign, marketers are able to deliver innovative email marketing campaigns by: 

  • Interacting with customers directly within email: Marketers will no longer have to rely solely on embedded hyperlinks. With AMP, customers will be able to interact with polls, make reservations, manage subscription preferences and more all directly within their email itself. Information captured in form fills syncs directly into Adobe Campaign, so marketers can build engaging email campaigns and gain actionable insights on their marketing efforts all from within the same application.   
  • Updating email content in real time: Content in static emails can quickly become out-of-date or irrelevant. Now information that is updated on a brand’s website can also be updated in real-time inside an email, even after it has already been sent. Thus, giving consumers the latest and most pertinent information and saving marketers the hassle of having to send out an additional message with updated information. For example, a retailer may have sent out a personalized email to a customer suggesting a new coat for the customer to purchase based on past behavior. At the time the email is sent, the coat may not be discounted, but by the time the customer opens the email, the coat is discounted 15%. The new price will be automatically updated within the email, providing the most accurate pricing to inform their purchase decision.  
  • Building dynamic customer experiences quickly and at scale: By leveraging AMP modules within Adobe Campaign, marketers can quickly and easily build interactive, personalized email experiences for customers regardless of the email client. AMP for email is currently supported by Gmail, Outlook and others.  

For more information on Adobe Campaign, click here.

How The United Nations Development Programme Engages Audiences With AMP Stories And MakeStories


Editor’s Note: The following guest post was written by Pratik Ghela, Product Manager – MakeStories.

Visual storytelling helps businesses and organizations engage their audiences in immersive content experiences. And putting together compelling online and mobile stories doesn’t have to be difficult. That’s why we created MakeStories, an online drag/drop building tool for AMP Stories. We provide users with a library of royalty-free stock images, illustrations, and other graphics to bring their storytelling to life. With no coding knowledge required, our goal is to give even non-technical people the tools to quickly and easily build AMP Stories around their brand content.

To give some insight into the process of creating an AMP Story, we are sharing a conversation we recently had with one of our users, the United Nations Development Programme. We came to learn about their work with AMP Stories through Twitter, where our team would help them answer product questions they had. With some support from our team, they were able to create a powerful Story about the Sahel region in Africa to share with the world. 

The UNDP’s Story combines dramatic photography and video of the region’s people and places, with captions and graphics describing the humanitarian, economic, and environmental challenges and opportunities in the area. Its click-through format is easy to view on both mobile and desktop devices, combining photos, videos, narrative, and graphics to create an immersive storytelling experience.

Here’s what UNDP’s Digital team had to say about how they created their Story: 

How did you hear about AMP Stories? Why did you think Stories would be a good fit for the UNDP?
We noticed a great story published by the Washington Post on the Hong Kong protests. We were impressed by the immersive experience and started researching the technology stack used for its production. We discovered that it was an open format called AMP Stories and decided to give it a try. 

Tell us about the Story you made… 

We wanted to highlight UNDP’s work in the Sahel region in a powerful visual format. The Story shows the potential of investing in the region’s youth and natural resources, which could help address the triple threat of poverty, exclusion, and climate change.

UNDP’s Story on the Sahel

How did you choose your subject matter and what made it a good fit for Stories?

The timing was good because the Intergovernmental Panel on Climate Change (IPCC) had launched its new report on Africa. Also, the G7 Development Ministers’ meeting was focusing on the Sahel and made announcements about UNDP projects in the region, such as a youth entrepreneurship initiative. We had impactful photos and raw video footage from the Sahel region, so we thought that AMP Stories could be a good opportunity to explore a new storytelling format. 

How did you decide to use MakeStories?
Our own development resources were tied to other projects, and we wanted to see if such a Story could be produced by someone without a programming background. We had already experimented with other multimedia story platforms, but the AMP Stories format seemed like it wasn’t too complicated to produce, which made MakeStories a quick winner.

Can you tell about the process of making a Story?

The process was pleasant and smooth. MakeStories allowed our graphic designer and editors to build a Story from scratch without developer intervention. The challenges we faced at the beginning were understanding the tool and being able to generate templates to have a coherent look—and that took about 8 to 10 days to build. We worked with the MakeStories team throughout the journey, including when we had questions, which made the process even simpler. 

UNDP used MakeStories editing templates to build their Sahel Story.

What was your experience like hosting the Story once it was created?
It was absolutely seamless. MakeStories offered a landscape view mode feature available on request that helped us to get an idea of the landscape version before uploading. Landscape mode required minimal customization thanks to the way the HTML/CSS is coded. We downloaded the exported package, added some customizations and after that, we just put it into the Github repository and published via Github pages.

MakeStories give you several options to publish your Story

How was your Story received by viewers?

We have received a lot of positive feedback from colleagues and partners who praised the creativity and engaging experience with this Story. The Story was posted prominently on our site in the top image slot and on social media. Additionally, the Story surfaced in Google Discover, which drove a significant amount of traffic.

How were people interacting with your Story? Did you see different behaviors on desktop and mobile?

We did not track the number of clicks. We saw that 75% of views of the English version were from mobile, but the average time on the page was longer for views from the desktop. This shows that while the format looks like mobile-first, it works on desktop as well.

Can you tell us the range and types of stories, campaigns, or initiatives you might use AMP Stories and MakeStories for in the future? 

We might use AMP and MakeStories in the future to promote our multimedia pieces where we showcase our headline stories, with fresh visual and editorial content from around the world. MakeStories is a good fit for our storytelling efforts because it allows us to quickly create a Story from scratch without the need of a developer, where the designer can create slide templates and the editors quickly edit into different languages. 

Have you produced additional Stories? If so, what MakeStories features did  you use?

After our first experience with MakeStories, we created a second Story about how climate change will affect the way we eat and all the hidden costs of unsustainable food production. For this Story, we used illustrations (and animations in some slides) to explain, complement, and clarify some of the facts in the text to create a more engaging and appealing Story. 

What would you tell other organizations about Stories and MakeStories? 

Storytelling is essential for advocating for sustainable development. As an organization that constantly produces stories and digital experiences, having a platform that allows us to create appealing and intuitive content with low effort in the production process significantly improves our efficiency and experience we offer to our audience.

Storytelling is who we are. It’s how we connect with each other. Since the first humans carved out scenes on cave walls, people have used visual storytelling to share information and experiences. The tools for future storytelling are evolving, with engaging new ways of conveying information, and users now prefer tappable stories for consuming content on the web. 

What stories could you be telling to inform your audiences and engage them in your mission? As the folks at UNDP describe, MakeStories makes it easy to create visually compelling stories and share them with the people you want to reach—in a mobile-friendly, easy-to-view, click-through format. Check out MakeStories and get started with your first Story today.

Written by Pratik Ghela, Product Manager – MakeStories

Creating Delightful User Experiences Using AMP On Adobe Experience Manager


Editor’s Note: the following guest post was written by Matthias Rohmer, Development Director at Jung von Matt

TL;DR: Jung von Matt helped BMW drive amazing user experiences using AMP on Adobe Experience Manager.

It’s fairly uncommon that you are free to choose which technology to use to implement for a client’s project. Clients that have chosen an enterprise solution usually seek products and services that complement those choices while allowing for future growth.

When BMW was searching for a company to partner with to rebuild the brand’s website in 2017, they were looking for that complementary solution. As almost all of BMW’s websites were built using Adobe Experience Manager (AEM), they were looking for a team that was able to both deal with such a high-end system as well as use its capabilities to build an easy-to-maintain, high-performance website.

This was a goal BMW had missed with their already-existing sites. Despite sharing the same backend, they were based on a variety of frontend frameworks and libraries. Fairly early in the process, we decided to bring some fresh air to this stack. Therefore we wanted to introduce AMP as the governing frontend technology. That was where our heads began spinning: what would be the best way to integrate AMP with AEM, especially with a CMS that makes so many assumptions about your frontend development?

Problems to solve when integrating AMP with AEM

After some research it occurred to us that there were three main challenges that we would need to solve in order to render valid AMP pages from AEM: 

  • As AMP requires all of a document’s CSS to be inlined in the <head> we would need to find a way other than AEM’s built-in ClientLib functionalities to render our CSS
  • For all of our pages to be AMP valid we would need a mechanism to only render resource hints (<script async custom-element="amp-carousel" src=""></script>) for AMP components actually used on a page
  • To be able to progressively enhance the website for returning visitors, AEM would need to be able to render AMP and non-AMP pages at the same time

Inline CSS with AMP

AEM has a fairly streamlined approach of handling a page’s styles: the ClientLib mechanism will take care of combining all the CSS needed for a page based on so-called categories. Based on those categories you can then let AEM create <link> tags in your templates. These will point to built stylesheets containing all your styles.

With AEM’s built-in rewriter pipeline we can use those <link> elements to combine those stylesheets into a common <style amp-custom> tag. The following (highly compressed) code-snippet should give you an idea of how such a transformer might look:

StringBuilder styles = new StringBuilder();
boolean writeStyles = false;

public void startElement(String uri, String localName, String qName, Attributes atts) throws SAXException {
	if (localName.equalsIgnoreCase("link")) {
		// If the element currently in queue is a link tag inspect it
		String href = atts.getValue("href");
		String rel = atts.getValue("rel");

		if (rel.equalsIgnoreCase("stylesheet")) {
			String css = "";
			// TODO: Load the stylesheet from the JCR, store it with others loaded
			// so far and append to styles


	if (localName.equalsIgnoreCase("style")) {
		if (atts.getIndex("amp-custom")) {
			writeStyles = true;
			// TODO: Use this flag to emit all styles gathered in styles
			// in the transformer's characters method


	contentHandler.startElement(uri, localName, qName, atts);

Only add needed resource hints

Another challenge we needed to solve in order to ensure AMP validity was to only add those <script> elements to the page that are actually needed. We did so by introducing a custom node type to our project:


Each of our AEM components has a child of that type holding information about what AMP component it relies on (amp-video in the example above). The advantage of using a custom node type here is that we can safely and quickly query those nodes when a page gets rendered to determine the required AMP components. In code this looks similar to the following:

final PageManager pageManager = resource.getResourceResolver().adaptTo(PageManager.class);
final String currentPage = pageManager.getContainingPage(resource).getPath() + "/jcr:content";

final String query = String.format("SELECT * FROM [bmw:ampResourceHint] AS s WHERE ISDESCENDANTNODE(s,'%s')", currentPage);

final Iterator<Resource> result = resource.getResourceResolver().findResources(query, Query.JCR_SQL2);

while (result.hasNext()) {
	Resource queryResource =;
	final String type = queryResource.getParent().getResourceType();
	ValueMap properties = queryResource.adaptTo(ValueMap.class);

	String[] usedComponents = properties.get("bmw:usedAmpComponents", String[].class);
	if (usedComponents != null && usedComponents.length != 0) {
		// TODO: Store all used components somewhere for later rendering

This piece of logic can then be easily called in an HTML template by using a data-sly-use attribute in combination with data-sly-repeat to print all required resource hints to the head of the page.

Serve AMP alongside a PWA

For we wanted to make sure that the site lands on the user’s screen as fast as possible. To achieve this every first-time visitor will receive the AMP version of our page. At the same time, we wanted to implement features that AMP alone could not offer but a PWA (which is still based on AMP!) could.

This means that our application would need to be able to serve two versions of the same document. Luckily for us this functionality is already available with AEM by using Sling selectors.

To establish a selector all you need to do is implement two templates alongside each other. The one the Sling engine should resolve to by default is simply called html.html. The other one is named after your selector. In our case it’s pwa.html which makes all of our articles either accessible in their pure AMP version via brooklyn-beckham-car-photography.html or brooklyn-beckham-car-photography.pwa.html with our PWA features.

Using this method, we had found a way to independently serve our valid AMP pages alongside our PWA. But how would a user ever end up on our Progressive Web App? That was where amp-install-service-worker had its shining debut. By using this AMP component, the is installing a Service Worker as soon as the user visits one of its pages in any of the AMP caches. From that point on we were then able to rewrite all requests going to brooklyn-beckham-car-photography.html to brooklyn-beckham-car-photography.pwa.html instead in order to silently enhance the user’s experience.

For us, those three were the main challenges when we were building BMW’s new international marketing website. In the end, all of them were solvable without reinventing the wheel, by using functionalities that are already built into AEM and AMP in creative ways.

AMP and Adobe have teamed up with Bounteous to make it even easier to build AMP sites on Adobe Experience Manager. Learn more and get started here.

Written by Matthias Rohmer, Development Director at Jung von Matt

People Behind The Code: NDTV’s Rise To Global Heavyweight


New Delhi Television Limited (NDTV) is one the most-watched news networks in India. They were also pioneers in bringing their content online with an accessible, user-friendly design.  

As smartphones became more affordable and accessible, mobile usage exploded across India in 2015. However, mobile data speeds also varied wildly from region to region. NDTVs development team quickly honed in on fast loading times as a way to gain a competitive edge, so they became early adopters of AMP. 

Vikas Kumar, NDTV

We caught up with Vikas Kumar, the head of NDTVs technology team, to talk about the impact AMP had on their mobile-first approach. 

Could you give us a bit of background on your company, and what made you decide to use AMP? 

NDTV launched in 1988 as a production house for Doordashan, a state-run news channel. We eventually launched our own independent channel, with dedicated content across news, sports, entertainment, finance, tech, to name just a few. 

We launched in 1999, and in the last two decades have grown into one of the top 20 news websites in the world. Through a commitment to quality content, UX, and localisation (our content is available in English, Hindi, Tamil, and Bengali), we now average close to 200 million monthly active users. 

We always saw page loading time as key to growing our online audience. One of our team members read an article about AMP, which got the developers talking. Our Google Account Manager sent us an email about it the day after, so it seemed like fate was calling!

Overall, we felt that AMP’s faster load times, and optimizations like pre-caching on SERP, could help us deliver a superior user experience.

Did integrating AMP present any challenges?

No, not really. Our SEO had been moving away from desktop towards mobile for some time, and with mobile index first taking precedence over desktop search, we knew it was the right option. 

We had some initial doubts about integrating third-party widgets, and whether or not we could maintain the existing look and feel of the site, but we found easy workarounds for everything. For example, <amp-iframe> is very useful for rendering widgets or elements that use custom JavaScript.

How did AMP impact your business? 

For ad-supported sites like ours, more impressions means more revenue. The faster loading pages and better user experience helped us establish a regular audience and generate income that we could reinvest into site expansion.

In this industry – even a one second difference has a massive impact in reducing bounce rates and increasing average session duration. After implementing AMP, average First Meaningful Paint (FMP) went from three seconds to one. 

AMP also prevents render blocking JavaScript by making it Asynchronous, and it eliminates third-party JavaScript which drags on loading time. It made us fast and agile. 

Our competitive advantage has decreased over time, as most publishers in India have embraced AMP and also take advantage of the platform. However, AMP really helped establish the channel with our target audience from the get-go. 

What advice would you give to anyone considering AMP? 

Make sure you familiarize yourself with all of the available AMP components; it will help you build a strong initial site framework. 

You should also continuously assess whether or not your AMP pages are valid, and if they’re not, take the time to understand why. The AMP website has resources for everything you could hope for, so we visit all the time.  

Did you find any AMP components difficult to implement? Are there any components you’d like to try out? 

We found <amp-live-list> a bit tricky to begin with! We wanted to run graphics of real-time election results on our site, but the third party JavaScript in it caused a problem.

In the end, we just posted our problems to the community and it was great that we could find a solution with the help of fellow developers, because AMP is open sourced, it’s constantly evolving so it’s great to collaborate and help each other.

We’re really looking forward to testing <amp-web-push>, which just launched recently.

What excites you most about the future of AMP? 

News like AMP being part of the OpenJS foundation gives us confidence that it’s being built with publishers and developers in mind, and is an open platform. New components and experiences like AMP Stories just add to the excitement. AMP+ PWA with one line of code would be awesome to have!

Vikas and his team are excelling with AMP – and you could too. Check out the resources on for everything you need to further your career with AMP. Grow your AMP skills.

Have you been using AMP as part of your strategy? Tell us your story! 

To stay up-to-date with the latest news, features, and tips about using AMP, sign up for our newsletter.

Posted by Alex Durán, AMP Project Marketing at Google