How to correctly measure the success of your AMP pages


Editor’s note: the following guest post was written by

Swetha Gopalakrishnan, Web Ecosystem Consultant, Google

Avneet Singh, Technical Account Manager, Google


Measuring the success of AMP pages is crucial for any business. As a developer or an AdOps person in a publishing company, you might be wondering how to measure the quality of your implementation and the monetization of AMP.

This is the first of a 3 part mini series addressing exactly that. We will be sharing best practices and common pitfalls we’ve observed over many publishers whom we have worked with. The mini series consists of:

  1. How to measure the success of your AMP pages (this article)
  2. AMP monetization best practices and common pitfalls
  3. AMP implementation best practices and common pitfalls

Let’s dive in!

There are 3 categories of success metrics you need to measure:

  1. Traffic (are users landing on AMP pages?)
  2. User engagement (are users spending time on AMP pages?)
  3. Monetization (are AMP pages making money?)


Objective: Identify if traffic is being channeled to AMP pages.

Metrics to collect:

  1. Source/Medium traffic split for AMP vs Non-AMP
  2. Number of sessions starting from AMP
  3. Cache vs. Non-Cache analysis

If you are using Google Analytics, you can create a new segment to analyze AMP behavior. For example:

Source/Medium traffic

Look for an increase in AMP traffic across the board. If you would like to compare this report against Non-AMP, remember to add a comparable segmentation for Non-AMP (eg. if only articles are AMP, use a Non-AMP segment filtered for articles only).

If you see referral traffic coming from “ / referral”, this means that pages served from AMP Cache are incorrectly counted as referral traffic. Ensure that a referral exclusion is added in GA (see step 3) for the AMP Cache domain (eg. 

Number of sessions starting from AMP, Cache vs. Non-Cache analysis

The number of sessions starting from AMP give an indication of whether users are discovering and clicking into the AMP pages. Cache vs Non-Cache analysis gives insight into how many users are accessing AMP pages via cache vs directly on your domain. 

In order to collect these metrics, add the following custom dimensions into the analytics tracking in AMP pages:

1. Add a new custom dimension via the Analytics interface. Make it a session level dimension and note the index number. This will identify sessions that start from AMP

  • Let’s say the index number is 1

2. Add another custom dimension, make it hit level and note the index number. This will track the Number of hits to AMP Cache vs your own domain.

  • Let’s say the index number is 2

3. Add the highlighted tracking code into your <amp-analytics> component

<amp-analytics> <script type="application/json"> { "vars": { "account": "UA-xxxxxxx-x" }, "triggers": { "trackPageview": { "on": "visible", "request": "pageview", "extraUrlParams": { "cd1":"AMP", //Identify sessions starting from AMP "cd2":"${ampdocHost}" //Compare cache vs non-cache traffic } } } } </script> </amp-analytics>

4. Relaunch your AMP pages and check that custom dimensions are being sent

5. Access the custom dimension in any of your normal reporting processes (eg. in GA, add the custom metric as a secondary dimension or use in a segment filter)


Case Study: KG Media boosts pageviews and mobile web revenue by increasing AMP traffic

KG Media, one of the largest media groups in Indonesia, is a great example of how channeling traffic to AMP benefitted their business and users. They learned that despite a high adoption rate (87% pages have an AMP equivalent), there was not enough organic traffic coming from AMP. After using GA data to understand user journeys and increasing the Number of AMP pages and traffic, they managed to see a 600% uplift in monthly AMP pageviews and a 34% uplift in overall mobile web revenue! (Read more)

User Engagement

Objective: Assess if users are spending time on your AMP pages and whether you are retaining users on AMP.

Metrics to collect:

  1. Bounce rate
  2. Pages per session

Bounce rate:

Bounce rate is when a user opens a single page on your site, triggers a single request to the Analytics server and exits the session without triggering any other requests to the Analytics server. Ensure that the AMP Linker has been implemented and track bounce rates on AMP to assess if users are engaged.

Pages per session:

Measure this metric for users whose session starts from AMP. This can be an indication of the quality of the AMP experience and assess whether users are retained on your site. 

If pages per session are not on par with non-AMP, check the UI and feature parity of AMP pages. Ideally, users should not be able to distinguish your AMP and Non-AMP pages (except that it loads faster of course!)

Case Study: saw a 50% reduction in bounce rate after AMP Linker implementation, one of the most popular entertainment sites in Indonesia, implemented AMP Linker across several properties and subsequently saw up to 50% reduction in AMP bounce rate (which ultimately reflects the true bounce rate) and a ~3x increase in pages per session for one of their properties. This enabled them to get more accurate insights on user behavior.


Transition to a new component framework for mobile web is an exciting new step to improve the user journey. Publishers often ask us what they can do to increase the monetization potential on their web properties without losing focus on a smooth user experience. A faster page load speed and a simplified structure ensures that ads on AMP loads faster, thereby giving users a higher probability to engage with ads on your AMP page. A better viewability and higher CTR paves the way for increasing the chance of better CPMs. The first task, however, is to ensure that you are measuring monetization on your AMP pages correctly. 

While revenue continues to be the north star metric that we want to maximize, the scale of adoption of AMP pages can be different for different publishers. Hence, our recommendation is to track a new metric which we call ‘Yield’ to compare monetization on AMP vs non-AMP. Yield is the product of coverage (matched requests/ ad requests) to the Ad eCPM. A readily available metric which is a good measure of Yield is the Ad Request eCPM.

To check open auction AMP performance on Google Ad Manager, add filters that help you look at data only for the mobile web and then compare AMP and non-AMP inventory in parallel. This can be achieved by adding filters for setting Products to ‘Display’ and Device Categories to ‘High-end mobile devices’. The dimension ‘Inventory Type’ helps compare AMP and non-AMP inventory perfectly well.

The output for this sample AdX historical report looks like this:

This is a great way to see that even though AMP revenue is half that of non-AMP due to fewer ad requests (usually a good proxy for AMP adoption), the Ad request ecpm and hence yield on AMP is 3x that of non-AMP. This is purely a function of higher Coverage and Ad eCPM. Data points like these can be good indicators for Ad Product Managers to make a business case with the web development team to increase AMP pages and inventory to earn higher revenues.

Publishers on Adsense too can measure their AMP pages performance in a similar way. Under the Content Platform reports, set Device categories to ‘High-end mobile devices’ and choose Content Platform categories to segment data by AMP and Web.

Case Study: JNM saw 3.3x ad requests, higher AMP pageviews and revenue through best practices

Jagran News Media (JNM) made user-centric, data-driven decisions and adopted best practices for ads running on AMP pages. Consequently, they achieved impressive results within a month. Ad requests were 3.3 times higher, generating 15% more mobile web (mWeb) revenue. JNM maintained their momentum by quickly enabling AMP for top traffic landing pages. They subsequently saw 115% more AMP pageviews and 4.5 times more AMP revenue.

(Read more)


Measuring and monitoring how your AMP pages are performing is key to success and informed decision making. In the coming weeks, we will deep dive further into the following topics:

  • AMP monetization best practices and common pitfalls
  • AMP implementation best practices and common pitfalls

Additional Resources

VICE Web Stories engage readers with a range of lifestyle content


Editor’s note: We’re running a series of blogposts on Web Stories, a content format that lets publishers and other content creators easily produce fast-loading, full-screen experiences that bring together visual narratives, engaging animations, and tappable interactions that entirely belong to them.

For this edition, we chatted with VICE Digital’s Senior Director of Innovation Sarah Singer to learn how VICE uses Web Stories to help readers find fun ways to stay healthy and fit.

VICE Media Group is an international media company with offices in 35 cities around the world. The brand has a reputation for edgy investigative journalism. VICE Digital, which covers news, tech, music, food, health, identity, money, and more, began publishing Web Stories in mid-March 2020 and is now producing over 10 stories a week. “We wanted to meet our audience in this moment by engaging them in this powerful storytelling format,” shares VICE Senior Director of Innovation Sarah Singer. 

How did VICE decide to start publishing Web Stories on cooking and fitness? 

Sarah Singer: We wanted to create evergreen content to tap into what people are searching for online today, especially things to help them support their physical and emotional health. Our cooking and fitness franchises provided great content for VICE to start populating our Web Stories. For example, we adapted a long-form article from our Munchies channel to create How to Make a Recipe Work if You Don’t Have All the Ingredients. This appeals to people who want to make something from just what they have stocked in their pantries.

As another example, we adapted a vertical video from our Ask a Swole Woman series featuring Editorial Director Casey Johnson. [Editor’s note: “Swole” means muscular or jacked.] In How to Get Swole at Home, Casey guides readers through a workout using just a few fitness tools. 

And since mental health is top of mind, we also did a wellness piece called Virtual Therapy Kind of Sucks: Here’s How to Make It Better.
VICE How to Get Swole at Home Web Story

What about the Web Stories format appeals to VICE readers?

SS: Web Stories are highly visual, they’re highly dynamic, and the format itself is so cool in terms of the user experience and consuming mobile video. That’s really inspiring to me. Web Stories goes beyond video—a passive experience where you just click “Play.” Here, you can determine the speed at which you go through a story, which is a more dynamic, engaging, and active viewing experience. For how-to stories like our cooking and fitness stories, this allows readers to slow down and go back and review any page. 

In addition to how-to stories, have you published other types of Web Stories? 

SS: We like to use Web Stories to transport readers to another place. A great example is Dog Utopia: The Town with More Dogs Than People. It’s about a refuge in Costa Rica for over 1,000 stray dogs, adapted from our VICE Shorties videos. We also adapt Web Stories based on photo essays, such as Eerie Photos of LA on Lockdown and Photos of LGBTQ People’s Chosen Families. Whether using video or still photography, we try to distill our VICE stories into their essence for Web Stories. 

How did you learn to build your Web Stories? Did you use a story builder? 

SS: For the videos, we recut the original videos most of which were edited into a 16×9 format. We then uploaded the vertical cuts into the VICE-branded templates we built out for Newsroom AI.

For the videos that were shot and edited in vertical originally, we upload the files without doing another visual edit. For the text-based stories, we write a script based on the narrative arc of the original story, and then build out individual story pages according to that script in the Newsroom CMS. We add the templates and VICE branding to the pages from there. 

How do Web Stories help you keep readers engaged with VICE content? 

SS: We plan on experimenting with storytelling and building strong narratives in the format, then allowing users to continue to engage with VICE after they’ve completed this experience. We put a link to other VICE properties at the end of every Web Story. Sometimes it’s an article, a YouTube page, a newsletter subscription page, a landing page…it depends on where we think the audience would want to engage further after completing the story.  

Any future plans for using Web Stories to share VICE content? 

SS: We hope to build as many Web Stories as possible and adapt as much of VICE’s tremendous library of content to this format as we can. Right now, users primarily find our Web Stories through online search or platforms like Google Discover. Down the line, we hope to house all these Web Stories within the online ecosystem of VICE. We’re excited about the multi-platform potential of this format and to bring our journalism to a broader, mobile audience. We want to build high-quality, thoughtful storytelling that can be best experienced in the Web Stories format. 

What would you tell other publishers thinking about trying Web Stories?

SS: Building Web Stories is a creative endeavor. It’s like looking at a blank canvas and figuring out how to adapt great storytelling to this format. When starting to build Web Stories, make sure to tap through and experience them as a consumer would. Gaining appreciation for the format as a user will help you create the best Web Stories possible for your brand.

Learn how to get started with Web Stories today with our guides, tutorials, and other tools.

AMP as a Service: 2020 Roadmap


This blog is part of a series that we are starting to share AMP’s roadmap with the wider web community.

We first unveiled our vision of AMP as a Service on a spring morning in Tokyo at AMP Conf 2019, our flagship conference. We talked about how engineering teams can accelerate their workflow by using AMP. So what has changed since the last time we talked about AMP as a Service? And what does the future look like for AMP? In today’s post we’d like to provide some further insight into our 2020 roadmap.

What is AMP as a Service?

AMP as a Service is our focus on making AMP the easiest way for developers to create high quality web experiences without being burdened by issues such as performance and infrastructure. AMP’s “evergreen” release schedule also means that these AMP experiences, once created, improve over time by becoming faster and more delightful without AMP users investing additional engineering resources. 

Last month, Google announced the Core Web Vitals program to shine a spotlight on a set of real-user performance and experience metrics that should be measured by all site owners. The AMP Project shared that a majority of AMP page loads already meet the thresholds set out in Core Web Vitals, which are a key component of a newly-announced Google Search page experience ranking signal. This means that AMP is really living up to its goal of being a well lit path to creating great user experiences.

Now, more so than ever, it is important that the AMP Project continues investing in AMP to put developers on the path to success to creating and maintaining great page experiences while simultaneously making developers more productive. We’re eager to do this work in 2020 and beyond.

Choosing AMP First to increase productivity

When choosing to create AMP pages developers can choose between serving paired AMP pages (creating AMP equivalents for their HTML pages) or having their canonical experience be powered by AMP. While paired AMP is a great way to get started creating AMP pages with the least amount of effort, development teams should think about how they want to set themselves to be productive in the long term while creating pages that perform well against Core Web Vitals.

Developers who leverage the AMP first approach will see their sites benefit from performance and UX optimizations across desktop, mobile and beyond. And this is why we encourage developers to use this opportunity to think about investing in AMP first. Here are a couple of strategies that could be followed: 

  • Using AMP for those subset of experiences that could benefit from AMP’s performance and user experience. 
  • Going fully AMP first for the entire site if AMP makes your team more productive and improves the user experience.

AMP Optimizer: web development best practices at scale 

Server-side optimizations for AMP pages are another area where we’re taking our lessons from AMP and are making them available to a wider audience. 

At the start of the AMP Project, AMP pages were mostly served from AMP caches and these performed additional optimizations enabling AMP’s strong user experience. However, over time more surfaces started linking to AMP pages and developers started using AMP for building their whole website. This has resulted in more AMP pages being served from origin, where there is room for improving AMP loading performance. To address this, we created AMP Optimizer, a tool to bring AMP Cache optimizations to experiences on the origin.

We use AMP Optimizer for the official AMP website, and by doing so we achieve the same performance as when the page is served from an AMP cache. AMP Optimizer fits really well into our idea of AMP as a service. It enables us to automate web development best practices such as image optimization or ESM module support. Check out how to integrate AMP Optimizer in this guide!

AMP Optimizer Frameworks and CMSes

Our goal is to make it easy to publish optimized AMP by seamlessly integrating AMP Optimizer into frameworks and CMSes.

The Next.js integration is a perfect example for what a great AMP development experience looks like. Next.js has a special AMP mode that results in the generated page being valid AMP. The cool thing is that you can start using AMP components straight out of the box and you don’t need to worry about the AMP boilerplate or importing AMP components. All this is automatically added by AMP Optimizer which is integrated into Next.js. 

Another example is the official AMP WordPress plugin, which publishes optimized AMP by default. This means if you use the official AMP wordpress plugin you get AMP cache like performance out of the box.


We’re just getting started. AMP Project contributors will continue working hard to ensure site owners get the strongest performance and user experience when creating AMP pages with minimal ongoing effort.

Posted by Naina Raisinghani, Product Manager, AMP Project and Sebastian Benz, Developer Advocate, Google

AMP graduates the OpenJS Incubation program


This week developers and members of the open source web development community tuned into OpenJS World for an exciting few days filled with informative talks, online code labs, collaborator conversations, and much more. This is the first time AMP has had such a large presence at the event since announcing our intent to join the foundation last year, and we are very excited to be further integrating AMP into the OpenJS community.

Speaking of further integrating AMP into the OpenJS Foundation, we are thrilled by our joint announcement on Tuesday that AMP has officially graduated from the OpenJS Foundation incubation program and is joining the OpenJS Foundation as a Growth project! During OpenJS World keynotes, Malte Ubl, Principal Engineer at Google, the creator of AMP, and a member of the AMP Project’s Technical Steering Committee, announced the exciting news. 

AMP has officially graduated the OpenJS Foundation incubation program

AMP joined the OpenJS incubation program last year and since then, the collaboration between the project and the Foundation has been very beneficial. Graduating from the OpenJS Foundation Incubation program signals more opportunities for growth and diversity for the AMP community. In becoming a full-fledged OpenJS Foundation project, AMP can better deliver on its vision of delivering  “A strong, user-first open web forever.” But this wasn’t the only exciting AMP news to come out of the conference.

Watch Malte’s keynote from the event

As Malte mentioned in his keynote on Tuesday, we are also thrilled to welcome Kasiana McLenaghan to the AMP Technical Steering Committee. Kasiana is a Senior Product Manager at Axios, where she works on the company’s site, newsletters and CMS. 

Kasiana led Axios’ development of an AMP-first website, launched in February 2020. Before Axios, Kasiana held product roles in smart city and sustainability-focused startups in Silicon Valley. She earned a master’s degree in data journalism from Columbia University, and a bachelor’s degree in economics from Stanford University. The AMP Project welcomes Kasiana and we can’t wait to collaborate on the future of AMP!

Kasiana McLenaghan, Senior Product Manager at Axios and newest member of the AMP TSC

This year AMP also took part for the first time in the OpenJS World Collaborator Summit. From talks on the future of AMP to the latest on Web Stories, it was great to connect with new and old faces alike and share how we are all working towards a better web! Thank you to everyone who stopped by to check out our talks. While we couldn’t connect with you in person this time, we look forward to more opportunities to connect with you in the near future. 

“How to integrate AMP into your framework or CMS” was just one of the many talks from the Collaborator Summit

As we close out the week, we’d like to thank the OpenJS Foundation and everyone else who helped make the event a success. This week is a major milestone for the AMP Project and we couldn’t have made it this far without the support of the broader AMP community. As we look back at five years of AMP, we can’t wait to continue expanding our horizons even further within the OpenJS foundation. If you weren’t able to attend the conference, stay tuned and follow us on Twitter as we’ll be Tweeting out links to AMP talks from the Collaborator Summit in the coming weeks. 

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

Forbes serves up shots of rich, visual content with Web Stories


Editor’s note: We’re starting a series of blogposts on Web Stories, a content format that lets publishers and other content creators easily produce fast-loading, full-screen experiences that bring together visual narratives, engaging animations, and tappable interactions that belong entirely to them.

For this first entry of the series, we sat down with Forbes Design Director Alicia Hallett-Chan to learn about her Web Stories publishing experience.

Forbes magazine is best known for its coverage of the world’s wealthiest, most powerful, most successful business people. The traditional and online publisher reports on innovation, leadership, money, business, and lifestyle.

Recently, began working with Google to add Web Stories to their content mix. We spoke with Design Director Alicia Hallett-Chan about’s approach to creating Web Stories. She chose “Whiskey 101: What to Know About Bourbon, Scotch, Rye, and More” as an example to give us a close-up shot of the brand’s creative process. Whiskey 101 Web Story

How did you decide to create the Whiskey 101 Web Story?

Alicia Hallett-Chan: We originally ran “You’re Probably Wrong About Whiskey And Bourbon. Here’s The Truth.” as a long-form, interview-type article, working with some of the most credible distillers to answer questions like, “Just how important is the barrel to bourbon?” or “Is it acceptable to add a drop of water to bourbon before drinking?” We then identified it for a Web Story because we had great photos and quotes from people at the distilleries. So we needed to pare it down to 15 to 20 pages.

What type of stories work best as Web Stories?

AHC: Web Stories are a great format to tell short-form, visual, first-person narratives that are optimized for mobile devices. A good Web Story should be lighter on copy and heavier on imagery. So we can tell the whiskey story through animated quotes, looping video, and photography. And we’re able to rely on short bits of copy with full-bleed images and videos. It’s visually impactful and helps drive the reader throughout the story. 

It was really helpful to have the Web Story guidelines at the very beginning, which suggested focusing on evergreen content and lifestyle stories. So most of our stories are within travel, auto, spirits, entertainment, health, gaming, and general lifestyle categories. It’s a short-form, snackable way to tell that story. now produces about five Web Stories a week on topics ranging from “NBA Team Values 2020” to “The Most Romantic Private Islands You Can Rent.” We look to create stories readers can see themselves in, benefit from, relate to, or aspire to. We look for what’s going on in the world today and what interests and engages our readers.  

Tell us about the design elements in your Web Stories. Any tips or tricks to share? 

AHC:  We like to feature people on the cover when possible, such as in “The Highest-Earning Podcasters” and “Ten Richest People in the World 2020.” It’s really important to have an informative headline to tell people what they’ll get out of the story, like “Whiskey 101: What to Know About Bourbon, Rye, Scotch, and More.” It’s all there. It’s very clear. 

Many times we’re creating custom animations where the video is interacting or overlapping with the typography. And I think that’s really fun! Animation and motion are great ways to draw in the reader’s attention, whether it’s the text sliding in or an image panning. Even if you don’t have video for every story, there are still ways to incorporate motion. Just be sure it doesn’t seem gimmicky. 

How do readers find your Web Stories?

AHC: We serve them as stand-alone stories on, which readers can find through search. Now, we’re looking into how we could embed Web Stories into our long-form articles and have them live inside their own ecosystem on We’re still in the early stages of the process, and our editors are open to brainstorming new ideas for a Web Stories-first execution. 

Any other plans for and Web Stories in the future?

AHC: We’re talking about doing a video-only execution. We haven’t done that yet, but we do have a lot of great examples. It will be different from a workflow perspective, as we currently put all the copy and captions into the pages with Newsroom AI. The captioning needs to work across an iPad or an iPhone X, and all of the Android devices. We want to make sure that our stories are always responsive across platforms. I’m really looking forward to seeing how far we can take the Forbes storytelling on this platform.

Your advice for other publishers considering the Web Story format? 

AHC: Give your audience relevant content—understanding that we’re in very difficult times right now. Think about your evergreen content and how you could repackage your top-performing stories in this new, snackable format in a really smart way. And it doesn’t even have to be video based; it could be a long-form article like the whiskey piece, where we took out individual quotes to get those 15 pages. So I think most stories, if you really look at them and try to slow them down, could be turned into a Web Story.

Learn how to get started with Web Stories today with our guides, tutorials, and other tools.

Looking back at five years of AMP


Update 6/26/2020: Since this blog post went live, AMP has officially graduated from the OpenJS Foundation Incubation Program. See the news here.

This summer marks five years since the first line of code for AMP was written. The project has evolved, impacted by things like the dynamic nature of the web, changing user expectations, ideas and code contributions from the ecosystem, and more. We’ve listened carefully to publishers and the developer community, and have constantly iterated AMP in response to their feedback.

With the support of the AMP community, we have aimed to live up to our mission of providing a content format that puts users first, and in doing so, helps support the success of every publisher, merchant, and advertiser on the web. With a half-decade of experience and many insights gained, we’re looking back at the origins of the project, lessons learned along the way, and what might lie in the future for AMP.

The beginnings: A swiftly changing web and a fortuitous conversation

Before I was even a software engineer at Google, the web was beginning to grapple with its future, famously captured by Wired in its “The Web Is Dead” feature. Today, the web has evolved and continues to thrive, but in 2010 this article held more than a grain of truth. With the rise of mobile devices, apps and social platforms, many industries, news publishers in particular, were seeing a dramatic shift in consumer behavior, and the web was struggling to keep up. 

Web publishers faced incredible challenges in offering compelling mobile experiences – at the time, mobile web pages took an average of 19 seconds to open. Publishers had to not only learn how to design content for mobile, but also how to evolve their business model. The simultaneous rise of social platforms increased demands on publisher time as their focus was split between developing for the web and social. 

To address these challenges and changing user expectations on mobile, new content consumption formats emerged on news and social media platforms. These formats provided users a quicker way to access news with consistent user experience, but these formats were limited only to the platforms they were developed for. They also raised questions for publishers related to business model control and branding.

In the Spring of 2015, over a hundred journalists and technologists from around the world convened for Newsgeist Europe in Helsinki, an annual event hosted by Google to discuss the future of the news industry. As was traditional for Newsgeist, attendees proposed sessions, one of which posed the question: “What could Google do for news?” The resulting session focused on content distribution in light of the new proprietary news and social content formats, developed in part to tackle publishers’ growing UX challenges. 

During the conversation, news publishers expressed the need for a new potential open source approach for distributed content; it was initially referred to as a “portable content unit.” The idea was this “unit” could help meet increasing opportunities for syndicating content with a great user experience while maintaining publisher control over business model, branding, and presentation. Publishers also indicated that a new, open-source approach might encourage a greater degree of collaboration around a single format.

Shortly after Newsgeist, David Besbris, a VP of engineering in Google Search, started assembling a product team which I joined and we began early discussions about building the new distributed content format, which we officially started to refer to as Portable Content Unit (PCU). Early on, our team focused on engaging with publishers in order to deeply understand their industry’s needs. We kept asking ourselves the question that had started these conversations in the first place: “What could Google do for news?”

Our early conversations with publishers, starting with our Digital News Initiative Product Working Group, brought us to believe that a holistic solution that addresses both mobile experience design and performance could be a powerful option for publishers faced with a growing landscape of new content distribution opportunities. We extended this collaboration globally with discussions and planning sessions with publishers around the world. With this realization, we had a mission. We saw how critical it was for the news industry to improve web performance on mobile devices, and we got to work on making the PCU a reality. 

The early design of this project was driven by three questions:

  1. How can we make the web competitive with proprietary and native news consumption experiences on mobile?
  2. How can we do that while ensuring freedom of branding and monetization for the publisher?
  3. And how can we not only make these things possible, but really ensure that a broad range of publishers are successful?

The last question was really key: It had always been possible to achieve great user experience on the web–it was just not evenly distributed. This new approach would be about democratizing great experience: enable all publishers no matter their size, technical capabilities, or budget to ship highly performant web pages, rivaling the best pages on the web. 

I was lucky that in my previous project at Google, my work had focused on making it easier for engineers to achieve great results without having to be web development experts, which aligns closely with question (3) above. This meant that we could use the internal software developed for this previous work as the basis of the first PCU validator. The crucial insight being that folks don’t need to be experts to achieve a given outcome if a piece of software could instead tell them what to do if they made a mistake.

Our team met with a handful of publishers to test the new format, and dozens more shared their content feeds so we could experiment with it directly on their behalf. We changed the internal PCU name to the AMP Project, or as it was then known, the Accelerated Mobile Pages Project. After countless hours of publisher feedback cycles, we announced our first developer preview in October of 2015 with more than 30 publishers taking part, underscoring our belief that the success of this effort lay not in the leadership of one but in the leadership of many.

Based on feedback from publishers, AMP was designed to:

  • Retain maximum branding and user experience flexibility for publishers,
  • Support publishers’ business models without disintermediation by a platform,
  • Sustain publishers’ access to data,
  • All while matching the user experience of closed platforms and introducing innovations like privacy-preserving instant-loading content.
AMP sought to democratize great page experiences on the web by enabling all publishers no matter their size, technical capabilities, or budget to ship highly performant web pages. 

We made AMP open source because we wanted to create a feedback loop with publishers and the web ecosystem. Alternative content delivery frameworks offered publishers a way to deliver content quickly and with a consistent user experience, but were limited in that they were each only applicable to one platform. Our goal was to improve the web as a whole by improving the content experiences of the publishers we were collaborating with. AMP’s earliest versions focused on enabling publishers to create mainly static content pages featuring text, images, and videos. Because of the important role that ads played in determining performance, the developer preview provided basic ad support, with plans to expand quickly to accommodate more complex ad setups and additional monetization models. 

The early days: Listen, learn, and repeat

After launching AMP’s developer preview, we were happy to see thousands of publishers from around the world express interest in the initiative. While we were encouraged by the response, we also knew that AMP had a long way to go. Developing a new framework that was compatible with existing publisher business models meant continued work to understand publisher needs, involving many hours spent understanding analytics setups, advertising strategies, and paywall implementations. 

As interest in the project grew, we set up regular working groups where publishers could work with Google product managers and engineers on some of AMP’s most requested features, such as amp-analytics or paywall support. In addition to publishers, we also needed to engage with advertising tech and analytics providers, as they are intrinsically linked to publishers’ online business models. More and more ad networks added support for AMP over time: Today 240 different ad networks and 80 analytics providers support AMP.

Over the course of AMP’s first few years in the wild, we continued to collaborate with the various parties involved in the web ecosystem and made significant progress on addressing some of AMP’s biggest gaps. In 2016 we announced the AMP For Ads project, which tackled some of the feedback we heard from publishers about slow ads performance on their web pages. We introduced support for live-blogs that same year, which addressed a key early-stage publisher request to have AMP support more dynamic content experiences.

How criticism made AMP better

While we made a ton of progress in our first few years working on AMP, that progress was not without criticism. This criticism largely fell into two camps: concerns about the AMP URL and its potential impact on publisher traffic, and the AMP requirement for publishers to be eligible to appear in the Top Stories feature in Google Search. While we may not have gotten everything about AMP perfect on the first try, we always aimed to do what was best for the web with the tools available, and worked closely and diligently with publishers and users to evolve AMP to be better.

The URL challenge was complex. We wanted to achieve privacy-preserving instant-loading on the web, and based on the state of the the web platform available to us at this time used iframe-based loading, which led to the suboptimal URLs. We would have loved to achieve the same user experience without making any changes to URLs, but as is common with larger software projects, we faced a trade-off, in this case between great UX and an undesirable URL format.

To address the issue, we quickly connected with browser vendors to make sure that sharing URLs from AMP experiences would share the canonical URL of the document instead. While this didn’t address the issue at the core, it provided a good solution for one of the core use cases of URLs: When a user shared an AMP document, it would always feature the publisher URL. In parallel we looked for a longer-term solution and worked closely with the web standards community. This work culminated in a technology called signed exchanges, which launched for AMP in Google Search in April of 2019 providing privacy-preserving instant-loading under the publisher URL.  

Another point of criticism around AMP was that it was a required technology to participate in the Top Stories Carousel feature in Google Search. Top Stories was designed to provide users with an equally compelling news experience as other quick-consumption, UX-focused formats. We expected users would engage with more news articles, and they did. Over time we heard from developers that they’d rather have choices beyond AMP to participate in this feature, so in 2018 we set out to bring everything we learned from AMP to the rest of the web by establishing web-standards for the things we’d built on the application layer. This work culminated in Google’s recent announcement around page experience signals that provides a path to make all web content eligible for inclusion in the Top Stories Carousel.

Governance changes

In its first two years, AMP grew from a tiny open source project with just two contributors to a much larger one with over 700 individuals contributing over 10,000 commits running on many millions of websites. AMP was governed like many other open-source projects at the time, where most decisions were de-facto made in the project’s working groups, but the final decision making power lay with me, the project creator. As AMP grew, it became clear that this simple governance model was no longer appropriate for an open-source project with such broad impact. 

Driven by this insight, the AMP Project proposed a new governance model that moved the power to make significant changes to AMP to a Technical Steering Committee, with representatives from a range of other companies that have committed resources to building AMP. A separate Advisory Committee was established to represent many of AMP’s other constituencies, such as the publishers and platforms who use AMP. AMP Working Groups became more officially established to focus on certain aspects of AMP such as UI, infrastructure, accessibility, etc., and these groups had a clear mechanism for input in the decision making process. This proposal went into effect in November of 2018.  

Later that year, AMP announced its intention to move to a foundation, a decision we made after looking at the governance practices of other successful open source projects like Node.js and Kubernetes. Moving to a foundation offers projects like AMP the independence to maintain their own identities, technical focus and product direction while receiving key support services such as marketing support, legal support and more. After considering many options, the OpenJS Foundation stood out as an ideal home for AMP.

Robin Ginn, Executive Director of the OpenJS Foundation announces AMP will be joining the OpenJS Foundation’s incubation program at AMP Contributor Summit 2019

Engaging developers: A global community

The AMP Project would not be near where it is today without the support and contributions of the AMP community. In just its first year, AMP saw over 170 contributors push code to the AMP Project repositories. Today, AMP has over 1,100 individual contributors, the vast majority of whom are non-Googlers. At the annual AMP Contributor Summit, we’ve met face-to-face with the hundreds of developers who form a part of our open-source community. This year, we’re participating for the first time in OpenJS’s Collaborator Summit as AMP further integrates itself into the OpenJS Foundation. 

The AMP team has also had the opportunity to connect with developers and partners from around the world at our annual AMP Conf. With past locations including New York, Amsterdam, and Tokyo, we’ve met thousands of AMP enthusiasts in-person and over our livestream, sharing the latest and greatest about the future of AMP. In 2018 and 2019 we also hit the road with the AMP Roadshow, which gave interested developers from cities as far-reaching as Seoul, Lagos, Munich, Jakarta and more the chance to attend a free day-long conference to help them get started with AMP. 

The AMP team at Google presents at the very first AMP Conf in New York City in 2016

Unfortunately, we had to postpone AMP Conf and AMP Roadshows this year due to the global pandemic, but we look forward to connecting with the AMP community in other ways in the future.

To the future: Expanding beyond AMP

What started off as a small open-source project in 2015 has grown to be a framework powering nearly 10 billion pages online. With a large, engaged community of contributors, we’ve tackled websites, ads, stories, and email, opening the door for developers to create beautiful, highly performant experiences on the web. The technology behind AMP unlocked the potential to bring a plethora of new functionality to the web, ultimately helping to ensure publishers, merchants, and advertisers could invest in new ways of storytelling to reach an ever-changing user base. That said, there is more work to do to make it easier for users to access content, and to support the success of publishers, and we’re excited about the challenges ahead.

Today AMP is in the concluding phases of completing its transition to the OpenJS Foundation, a transition started last year. This long-awaited move continues to strengthen AMP’s open-governance model, and we can’t wait to expand our horizons even further within the foundation. To learn more about what’s in store for AMP, tune into my keynote talk at OpenJS World, a digital conference hosted by the OpenJS Foundation on June 23.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Principal Engineer at Google

AMP Camp: Cross-origin user state in AMP


tl;dr: This article will teach you how to track user actions between your domain and AMP Caches.

Welcome to the latest in our series of posts about AMP Camp, our demo that shows how to create an interactive site with AMP! In this series, we’ll discuss the techniques and tools we used in creating it, as well as best practices we developed. If you’re interested in creating an interactive site with AMP, we hope you’ll learn something!

In the previous post, we talked about how to use templates on both the client and your server. In this post, we’ll discuss best practices for tracking user state between your origin and AMP caches.

User state and AMP caches

If a user visits your site on an AMP cache and again on your own domain, it’s important to recognize that both visitors are the same person. This can take a little work. Fortunately, there’s a solution!

Imagine this: you run BestClips, a site that sells the most effective paper clips in the world. Each clip can hold up to 50 sheets of paper, and they’re completely made from 100% biodegradable soybeans!

Since you want users to see your clips as fast as possible, you built your product pages with AMP. You serve AMP pages from your domain, And when web spiders like Google’s and Bing’s discover these AMP pages, they get stored in AMP caches. So when a user discovers your product page in Google or Bing Search, they’ll be viewing it in an iframe on a site like or, and the page will be served from an AMP cache, such as or So far, so good!

But what happens if a user discovers your page on an AMP cache, they add paper clips to their cart, and later in the day they visit your site again on Will those clips still be in their cart? Or will the cart be empty?

(If your site uses a signed exchange, many browsers will show your origin domain even when your page has been served from a cache. In this case, this problem vanishes. Otherwise, it’s good to know how to deal with it.)

What’s the issue?

AMP caches help make your web pages fast while preserving user privacy! But a cache also introduces an extra level of complexity: users can access your site not just on your domain, but also on the cache’s domain.

Let’s say that, following standard web practice, tracks a user’s state by dropping a cookie that contains a session ID. Then, whenever the user visits your pages on, your server retrieves the cookie, reads the session ID, and restores the user state from data stored on your server that’s associated with that ID.

Now, let’s say the user visits your product page, they see some paper clips that they can’t live without, and they want to add those to your cart. They click a button, and your site submits data to your server:

<form action-xhr="/add-to-cart" method="POST">

If the user’s on your origin, the request comes with a session cookie. In part, the request would look like this:

POST /add-to-cart HTTP/2.0 Cookie: session_id=12345

But if the user’s visiting your site on an AMP cache, that request to your server might actually emanate from or – a different domain! The browser associates your cookie with, and thus it’s now a third-party cookie. Most browsers will cheerfully send these along. But users may have set their browsers to block third-party cookies. And some browsers will simply block a third-party cookie under certain circumstances. This would make your request look like this, with no cookie header:

POST /add-to-cart HTTP/2.0

What to do?

The solution, in brief

(For simplicity, going forward, we’ll use the term “origin” to refer to your domain, and “cache” to refer to an AMP cache.)

The solution is twofold. On your domain, identify users with a session cookie, just as usual. On the cache and on a browser that accepts third-party cookies, do the same. Otherwise, whenever a user takes an action that modifies application state, redirect them immediately to your origin, where you can access or create a cookie stored under your domain, and then make the change desired.

In other words, if the user wants to add paper clips to their cart, and if you can’t read their cookie, don’t panic! Simply redirect them to your origin, where you can change their cart to your heart’s content.

This redirect is made possible by an AMP-specific HTTP header called AMP-Redirect-To. If an AMP page makes a server request using <amp-form>, and the server’s response contains this header, AMP will redirect to the desired page.

Here’s the entire flow:

  1. The user navigates to the product page. If the user’s on the origin, the origin sets a session cookie if one isn’t already present.
  2. The user takes an action to change what’s in the cart
  3. The browser sends data about the change to the origin via POST XHR
  4. The origin checks whether the request contained no session cookie and came from the cache
    • If that’s true:
      1. The response tells AMP to redirect to a URL on the origin which includes a query string that describes the user’s change
      2. When the origin sees that query string, it reads or creates the cookie, makes the change, and redirects again to a URL on the origin that doesn’t have that pesky query string
    • If that’s not true, then we can simply retrieve the user’s session and make the user’s change. Either we’re on the origin, or we’re on the cache with a browser that allows third-party cookies.

Whether the user begins on the cache or the origin, by the end of this process they’ve got a session and their changes are reflected on the server.

The solution, in detail

Let’s describe this process in detail. Let’s say a user visits our product page and decides to buy one of our new Superclips. Our product page lives at, but the user might access this page either on our origin or on an AMP cache.

Step 1. The user arrives at our product page. This page contains a form that allows the user to select a quantity, and a submit button that allows them to add the product to their cart. This might look like this:

<form action-xhr="/api/add-to-cart" method="POST" <select name="quantity"> <option value="0">0</option> <option value="1" selected>1</option> <option value="2">2</option> </select> <input type="submit" value="Add to Cart"> </form>

Step 2. Let’s say the user leaves the quantity to “1” and taps “Add to Cart”.

Step 3. The form is submitted, and AMP sends an XHR POST request to our server, (To ensure that this request will work even from a cache, you need to set up CORS headers. If you’re using node, you can just plug in the AMP CORS middleware.) On the origin, the request looks like this:

POST /api/add-to-cart HTTP/2.0 AMP-Same-Origin: true Cookie: session_id=12345 quantity=2

Note that AMP conveniently adds the AMP-Same-Origin header when it’s running on the origin.

If the user’s on the cache with a browser that allows third-party cookies, the request will look like this:

POST /api/add-to-cart HTTP/2.0 Cookie: session_id=12345 quantity=2

If the user’s on a cache with a browser that blocks third-party cookies, the Cookie header will be missing as well:

POST /api/add-to-cart HTTP/2.0 quantity=2

Step 4. Now comes the fun part.

The server checks to see whether the request lacks a session cookie and came from the cache. If there is no cookie, then the browser hasn’t allowed a cookie to be set. That could also happen if the user’s browser blocks all cookies, in which case, redirecting to the origin wouldn’t help. We’d never be able to track the user’s state with cookies. This is why we also check to see whether the request came from the cache – because that’s the case we can deal with.

If the request lacks a session cookie and came from the cache, the request will lack both the Cookie header and the AMP-Same-Origin header, as shown above. The server detects this condition:

if (!request.cookies.session_id && request.headers['amp-same-origin'] !== 'true')

If that’s true, the server sends a response that instructs AMP to redirect to a URL on the origin. In that URL, it includes a query string that describes the user’s change, like this:

response.setHeader("AMP-Redirect-To", `${request.body.itemName}&quantity=${request.body.quantity}`);

This sends a response that contains a header like this:


When this response gets back to the browser, AMP notices the header and redirects to This request goes to, our origin! The origin server can then read the session cookie or create one if it doesn’t exist. It adds one superclip to the user’s cart. Then it redirects to

In other words, it redirects back to the product page without the query string. That way, the user won’t experience difficulties that could be caused by the query string. (See “Here’s how not do it” below for reasons.)

As promised, now the user has a session cookie and the change has been made on the server.

Can I use Client ID instead?

If you’ve worked with AMP, you may know that there’s the Client ID, which allows analytics packages to track a user’s journey from cache to origin. On origin, it’s stored in a cookie and persists for a year. On the cache, it’s also stored in a cookie, and if it’s not in the cookie, it can be created with a call to the Client ID API. So it would be tempting to use this to consistently identify a user.

Unfortunately, although sites do use this solution, it comes with flaws. The Client ID identifies a single user uniquely for certain journeys between origins and caches, but not all. And its cross-site behavior can be blocked by the same browsers we’ve been dealing with throughout this article.

The AMP Linker makes these cross-site journeys more reliable, since it preserves the client ID as a query string parameter. This provides another way to use the Client ID! But it does mean that the user’s unique identifier will then be visible in their URL. URLs tend to get logged on servers, and sometimes bad actors discover the log files. Worse still, the user might well share their URL publicly, exposing their identifier to the world. In either case, their session is vulnerable to hacking! This is why we used POST instead of GET in our examples above.

Do I really need to do this?

You may not. But as browsers block third-party cookies in more and more cases, this solution will increasingly be essential to let users use your site smoothly across your origin and AMP caches. And while the flow above takes some time to explain, it’s not hard to implement.


Check out how we did it in the AMP Camp demo site. Here’s the server code. And here’s the form on the product page. The only difference is that, on this demo site, when the user adds an item to their cart, we redirect them to the cart details page.

Written by Ben Morss, Developer Advocate

AMP: a well-lit path to optimizing for Google’s page experience signal

Web Standards

Google Search recently announced a new Search ranking signal centered around page experience. We’re excited by the potential for Google’s page experience signal to guide and empower developers to build a better web. Because AMP was developed to help enable development of user-first sites,  we believe AMP is a cost-effective and simple solution for publishers to create a great page experience. In today’s post, we want to step through what the announced changes to Google Search mean for the AMP community as well as the web ecosystem.

How AMP can help you create a strong page experience

Google’s page experience signal relies on a suite of metrics collectively known as Core Web Vitals, in addition to signals such as mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines. This emphasis on improving user experience across the greater web aligns well with the vision and lessons learned from AMP. Google performed an analysis using the Chrome User Experience Report showing that the majority of AMP page loads will meet the Core Web Vitals, and even more still when you allow for AMP cache-delivered page loads.

Earlier this month we detailed how AMP can help site owners meet the recommended performance targets outlined by Core Web Vitals. However, there are aspects of handling performance that are out of AMP’s control, such as image-optimization and server response times, that may result in a suboptimal page experience. Make sure to check out the guidance in this blog post to optimize your AMP pages for a great page experience. 

AMP Project contributors will continue working hard to ensure site owners get the strongest performance and user experience when creating AMP pages. With AMP, site owners can access these improvements without having to further invest money or engineering time. For example, recently we optimized numerous AMP components to improve measures of Cumulative Layout Shift (CLS), a Core Web Vitals metric that will contribute to the page experience signal. 

Google’s continued investment in AMP

Google will continue to invest in AMP, and strongly believes in the AMP Project’s goal to make it easy to create web pages that provide a great user experience. When available, Google Search will continue to direct users to the AMP versions of web pages in the mobile Top Stories feature. This behavior keeps in place hallmarks of the AMP experience, such as privacy-preserving pre-rendering that can happen when content is served from an AMP cache. This also means that the page experience signal for a given search result will be evaluated based on the performance of the AMP page when available.

The AMP Project will continue to focus on creating strong page experiences. AMP’s always up-to-date “evergreen” release schedule means AMP users will get future performance benefits as we make them, without investing additional engineering resources. 


Google’s roadmap for page experience is an exciting milestone for any web site or framework that prioritizes performance and user experience, including the AMP Project. We believe AMP makes it easy to not just create pages that are optimized for page experience, but do so with minimal on-going effort. 

Please let us know if you have questions or feedback regarding these recent announcements. 

In the meantime, we hope you are all staying safe.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Principal Engineer at Google

Stripo + AMP Dynamic Email Boost Customer Engagement


Editor’s Note: The following guest post was written by Dmitry Kudrenko, CEO, Stripo

Stripo offers businesses 350+ email marketing templates and a suite of email marketing design, editing, and management tools—for beginners and advanced users alike. We support many types of organizations and industries, from small businesses to large, multinational corporations, in 8 languages and 80 different countries. 

Companies come to us not only for tools to make their email marketing fast and easy, but also for innovative ways to stand out in their customers’ inboxes. For years, we’d been hearing things like “AMP for email is cool,” “AMP for email is great,” and “AMP for email improves the effectiveness of our email campaigns.” Given that we’re nerds who like to test things and analyze the results, we decided to check out AMP for email for ourselves. 

Testing Conversion Rates

Before offering AMP for email to our customers, we wanted to find out if it had a positive impact on conversions. So we created an email campaign asking our users to share their opinion with us about our tool. Recipients whose email clients didn’t support AMP had the option of leaving a comment in Google Forms. Recipients whose email clients did support AMP could comment directly in our email without ever leaving their inbox.

The Results: Of the 12K recipients who saw the HTML version and had to go to an external form to leave their feedback, only 18 left a comment. Of the 10K users who saw the AMP HTML version, 79 left a comment right in our email. 

The conversion rate of the HTML email was 0.15 percent, while the AMP HTML email conversion rate was 0.79 percent. The numbers speak for themselves: The AMP form was 5.2 times more effective than the traditional questionnaire.Our conclusion: AMP for email really does increase conversions, and straight from the inbox, too!

Introducing AMP For Email To Customers

Given the great results we had with our own test, we launched AMP for email tools for our customers in April 2019. We now offer a number of email templates that customers can customize with drag-and-drop AMP blocks to easily build innovative, dynamic AMP emails for powerful campaigns. 

We’ve been educating our customers on how to build AMP emails with Stripo. Currently only some email service providers (ESPs) are capable of sending AMP emails, and these ESPs will only send AMP emails if they also have a mandatory “fallback email”—a traditional HTML email that will display content differently if the user cannot view the AMP email interactive elements. So, for now, our customers need to combine both versions (an AMP email and a fallback HTML email) in one email campaign. 

To make things easy on our customers, we offer controls to help them craft a fallback HTML email within their AMP email with just a few clicks. We walk them through the steps including “Include in AMP,” “Include in HTML,” and “Include everywhere” controls. When their email is ready, our code validator checks it for errors. We’ve also educated customers on how to test their AMP emails, execute their AMP email campaigns, and then analyze the results to learn what works best for their audiences.

Most Popular AMP Email Components

Do we want to empower customers to build dynamic emails on their own, without coding skills? Oh yeah, we do! That’s why AMP for email is so great. The most popular AMP for email components among our customers are:

  • Image carousel: Adds a number of banners in one email instead of just one.
Example of the image carousel functionality
  • Accordion: Hides product descriptions to make emails shorter.
  • Lists: Lets users pull in real-time content. Works great in welcome emails!
  • Selector: Makes it easy for users to select item colors, sizes, features, booking dates, etc., directly in emails. Users fill out their request (and can even set dates for booking hotels and flights) in the AMP email and then proceed to the merchant’s website to check out.
Example of the selector functionality

Final Thoughts

We will soon be releasing our new AMP blocks—forms and lists—to let users implement these effective AMP components with little to no coding skills.

What the AMP team has done to make email campaigns more exciting and effective is, in our opinion, just great! They once again give us an opportunity to stand out in users’ inboxes—and to create and deliver more effective campaigns. But email template builders and email service providers alike need to help the AMP team spread the news about AMP for email, so it can become more widespread and universally supported by ESPs.

For more on how Stripo and AMP for email can help your business, visit Stripo Email. The Stripo team is happy to assist email marketers and designers in building emails powered by AMP.

AMP Camp: Using templates in the client and the server



Welcome to the latest in our series of posts about AMP Camp, our demo that shows how to create an interactive site with AMP! In this series, we’ll discuss the techniques and tools we used in creating it, as well as best practices we developed. If you’re interested in creating an interactive site with AMP, we hope you’ll learn something!

In the previous post, we talked about the build process used to create our site. In this post, we’ll discuss how to use templates on both the client and your server.

AMP is commonly used to serve pages instantly through link sharing platforms, what’s referred to as Paired AMP. In a previous post, we’ve discussed the benefits of using AMP as the primary framework to build your entire website, an approach that’s called AMP-First.

In this post, we’ll discuss how to produce dynamic content in AMP-First sites. That way users always access fresh data, whether they arrive at the pages from the AMP Cache, or from the site’s origin.

To achieve this, we’ll explore how to differentiate client-side rendered parts of the page (not mediated by the cache) from server-side rendered ones (that can be safely cached).

Also, to simplify our development we’ll see how we can use templates in the client and the server by using the same templating engine. This can make our code more readable and maintainable, as long as we make sure to differentiate clearly which parts have to be rendered by which layer.

As a recap, let’s review how content can be accessed in AMP-First sites.

Dynamic content in AMP-First sites

In AMP-First sites, users can access your pages on two different origins:

  • Site’s origin: These AMP pages are hosted by the site’s owner. Users commonly land on those pages by navigating the site’s URLs.
  • AMP Cache origin: These versions of the AMP pages are stored after being discovered by search engines like Google and Bing (for example at or Users commonly land on those pages after clicking on links from search results or link sharing platforms.

In the first case, site owners have full control on the caching strategies to apply, for example, by using traditional HTTP Caching strategies and/or service workers.

In the case of pages served from an AMP cache, even when the site’s owner can force updates (e.g. by using update cache API), by default the cache will follow a stale-while-revalidate model. This consists of checking the origin’s caching headers (such as max-age and s-max-age) on each user visit, and requesting a new copy to be fetched in the background, if the resource is stale. For that reason, one user might see stale data until the latest version of a page has been fetched.

For many sites, relying on the default behavior of the AMP Cache is acceptable. For example, frequently accessed articles on news sites are kept fresh automatically, and having, at most, one user see stale content from time to time might not be a big issue. 

E-commerce sites usually have stricter UX requirements: showing stale prices even to a single user could prevent an entire purchase, or what is worse, negatively impact the user’s trust on the brand.

In high impact cases, you can apply a mixed strategy for dynamic data, to make sure that critical fields are always fresh while leveraging the speed benefits of the cache for non-critical parts of the page:

  • Client-side rendered data: For critical fields (like prices) client-side requests can be used. These requests are not mediated by the AMP Cache, and can be implemented by using dynamic AMP components like <amp-list>, <amp-bind> and <amp-access>.
  • Server-side rendered data: Non-critical parts of the page that change less frequently (like a product title) can be fully rendered in the server. This is commonly achieved by combining dynamic data (from databases, APIs, etc), with static HTML templates.

As a result, when the page is being served, the resulting HTML code will contain fields already populated (non-critical), along with calls to components like <amp-list> for client-side generated ones (critical fields). 

In the following snippet, the parts marked in blue are server-side rendered fields, while the red ones are fields that will by resolved later in the client:

<div class="product-details"> <h1>Stretched Jeans</h1> <amp-list height="24" layout="fixed-height" src="/static/samples/json/product.json"> <template type="amp-mustache"> Price: ${{price}} </template> </amp-list> <p class=”product-description”>A classic choice for every day.</p> </div>

The code looks simple, but it’s the result of some complex work done in the backend. Next, we’ll explore how to achieve that by using popular web technologies.

Implementing a server-side rendering strategy

To put to practice the strategy discussed before, we’ll use a popular backend technology: Node.js.

As mentioned, for the server-side rendered parts of pages, you need some way of combining data fetched from APIs and databases with static HTML templates. In a Node.js environment, this is usually accomplished via JS templating engines.

There are many available options on the market. In this post, we’ll explore a popular one: mustache.js. Besides the fact that it’s easy to implement and widely used, one of the advantages of picking this templating engine is that it’s already used by AMP to render the responses of dynamic components, like <amp-list>, through a component called <amp-mustache>. This saves us the effort of learning another technology while keeping our code more coherent and readable.

A typical mustache template contains any number of mustache tags. By default these tags are written with curly brackets (e.g. {{price}} and {{availability}}).

Even when they are simple to write, these templates are “logic-less”, meaning you can use things like conditions in the templates, but not much more. Most of the logic will be executed and contained in data objects that are sent to these templates to populate fields.

The challenge of using the same templating engine for client and server is that we’ll be using the same tags to populate both client and server-side rendered fields.This can lead to collisions.

In the previous example code, if we were using the same default mustache tags {{ }} in the client and server, when the engine runs in the server, and finds the following code:

<div class="product-details"> <h1>${{product-title}}</h1> <amp-list height="24" layout="fixed-height" src="/static/samples/json/product.json"> <template type="amp-mustache"> Price: ${{price}} </template> </amp-list> <p class=”product-description”>${{product-description}}</p> </div>

It will replace each dynamic field with the value of the corresponding property in the object that is used to populate the template. The resulting version of the page will be:

<div class="product-details"> <h1>Stretched Jeans</h1> <amp-list height="24" layout="fixed-height" src="/static/samples/json/product.json"> <template type="amp-mustache"> Price: $50 </template> </amp-list> <p class=”product-description”>A classic choice for every day.</p> </div>

When the AMP page is served, the following sequence will take place: 

  1. <amp-list> will be executed at page load time.
  2. The response will be passed to <amp-mustache>.
  3. Since the price has already populated in the backend, mustache won’t find any dynamic fields to resolve.

This prevents our goal of making sure that the price is always fresh.

To avoid this, you can use custom delimiters, to declare a different set of tags in the client and the server. For example:

  • {{ }}: For fields rendered by <amp-mustache> with the result from <amp-list>.
  • <% %>: For fields populated by mustache in the server.

The resulting code will look like the following:

<div class="product-details"> <h1><%product-title%></h1> <amp-list height="24" layout="fixed-height" src="/static/samples/json/product.json"> <template type="amp-mustache"> Price: ${{price}} </template> </amp-list> <p class=”product-description”><%product-description%></p> </div>

By combining these delimiters in a template, the server will first populate all the fields marked with <% %>, and leave the ones marked with {{ }} untouched, so that they can be used by <amp-mustache> after <amp-list>  executes.

Going the extra mile: serving different versions of the page according to user agent

In the case of AMP-First sites, one could apply an additional optimization, by serving two different versions of the page to users and crawlers:

  • For crawlers – Mixed client and server-side rendered approach: The strategy discussed before can be applied only for requests coming from the Google crawler, by verifying Googlebot using a reverse IP lookup. When the crawler fetches the AMP URLs, those are the versions that are going to be retrieved, stored and served from the AMP Caches.
  • For site’s origin users – Fully server-side rendered approach: If the request doesn’t come from a bot, the page can be fully server-side rendered, so that user’s navigating the site from the origin don’t need to incur into any additional latency from <amp-list> requests unnecessarily.

That way, since users navigating on the site’s origin won’t run into the risk of seeing potentially stale content, there’s no need to make any client-side request for critical fields. In those cases, all the content can be fully server-side rendered, to avoid incurring potential latency of client-side requests.

Breaking up the serving strategy in this way ensures the best possible performance for users accessing the site from different surfaces.


In this post, we have explored a strategy to make sure that the AMP content served is always fresh by combining client and server-side rendered content in the same page. 

To that end, we explored how to use templates in the client and the server, by using popular web technologies: Node.js and mustache.js.

For concrete examples of application of this pattern, you can take a look at the code of AMP Camp

The product details page is a good example of applying this technique. It contains a mix of fields, written with different tags: {{ }}, for client-side requests, and <% %> for server-side rendered parts of the page, as discussed throughout this guide.

If you want to take this implementation further, you can analyze the user-agent of the request, and only serve mixed client and server-side rendered pages to search engines, while serving fully server-side rendered versions of those pages to users navigating on your origin.

Written by Demián Renzulli, Web Ecosystem Consultant, Google