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

Infinite recommendations with a new and improved amp-next-page


A key part of AMP’s mission is ensuring the “long-term success of every web publisher”.  To further that mission, we know just how important it is to help web publishers increase the reach of their content. Previously, we released <amp-next-page> as an experiment to help publishers turn an AMP page into a continuous scrolling experience by loading additional recommended content from the publisher’s website when the user reaches  the end of the document. This component was intended to help publishers increase engagement on AMP pages by increasing the time users spend on site.

We’re excited to announce <amp-next-page>, version 1.0! The release of version 1.0 comes with all the benefits of publisher testing and feedback from version 0.1. Read on to discover new features and learn how to migrate.

Forbes using <amp-next-page> version 1.0 (Link)

Why upgrade to version 1.0?

Support for infinite recommended pages

With <amp-next-page> version 1.0 you can load an infinite number of pages as opposed to version 0.1 which only allowed publishers to specify 3 recommended pages.

Analytics Support

The <amp-next-page> component supports analytics on the hosted page as well as on subsequently loaded pages as long as you are using <amp-analytics> and <amp-pixel> on those pages. This also means you can use any analytics provider that is supported by <amp-analytics>.

Two custom analytics events are also provided on the host page to indicate transitioning between pages. For more information on analytics support go here.

Customize separators to increase monetization 

<amp-next-page> renders a separator between each page to help the user delineate between two pages. While this separator does have a default style, publishers can also style this separator to reflect their brand. Publishers can go one step further to place <amp-ad> in this separator, to increase the potential for monetization as the user consumes more content on site.


Like other AMP components, <amp-next-page> is accessible by default. The default recommendation box and separator both have a generic, non-localized aria-label describing their content and are keyboard-focusable. The aria-label can also be overridden to accommodate localization.

Instructions on migrating to version 1.0

For instructions on how to migrate from version 0.1 to version 1.0 please visit the migration section in the documentation.

Our thanks go out to you, the AMP development community, for your feedback. As always, please let us know if you have any issues or feature requests.

Posted by Naina Raisinghani, Product Manager, AMP Project

AMP + Web Vitals – a better web, together

Web Standards

This week Google announced the Web Vitals initiative, a collection of guidelines highlighting what Google believes is essential to a good user experience on the web. Since the AMP Project’s goal has always been to ensure that the “web works better and faster for everyone, everywhere”, we wanted to share how AMP can help site owners meet the recommended performance targets outlined by Web Vitals. We will dive into the work that goes into making the web feel instant, and share what you should be doing to make it even better. 

What are the Core Web Vitals?

There is a lot to Web Vitals! We are going to be covering Core Web Vitals in this post; you can learn about the difference on Here is the most relevant information from that site:

Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools. Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.

The metrics that make up Core Web Vitals will evolve over time. The current set for 2020 focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds):

Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.

Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

Don’t get lost in the jargon, the key point is that these metrics help you make sure that a site is meeting critical user experience expectations, and they can be measured in the field via new cross-browser APIs.

All of these can (and should) be measured in the field, so you can keep track of what your users are really experiencing, not just results from a lab. Now that we know what makes up these new guidelines, let’s look at what AMP does to meet them. 

First Input Delay
First Input Delay (FID), helps you determine interactivity performance

Having a low FID score means that when users click on a button, or tap on an input, they don’t have to wait and the site responds near instantly. According to the documentation on, the goal here is 100 milliseconds at the 75th percentile. That means that the first time a user interacts with an input, it takes less than 100ms to react for at least 75% of the time when that page is viewed. Like all of the Core Web Vitals, this information needs to be collected from your users. If you aren’t already, you should be looking at reports for your real user data (hint: PageSpeed Insights is a great place to start) to see if you are meeting these thresholds, not just what’s measured on your development machines.

In fact, FID can’t be measured in development – the only way to get meaningful data is by seeing how long real users’ interactions take on your site. Total Blocking Time is a good analog to use while developing. They don’t measure the same thing, but if you reduce TBT, you will likely reduce FID! If you are seeing a lot of high FID values, it usually means the browser’s main thread is busy doing something else like parsing code, loading third party resources, etc. You can learn more about how to improve your FID score on

AMP works to keep your FID score low in a number of ways:

AMP’s code won’t block your users

AMP only allows asynchronous JavaScript. We make sure it isn’t accidently performing slow or computationally heavy operations that could otherwise block your users from actually using your site. 

Deferred layout

AMP delays rendering elements that are not likely to be seen right away during load to keep the site feeling instant. That means AMP won’t block the user from clicking and tapping because it is processing a heavy, JavaScript-powered video player at the bottom of your site right when your site loads. 

Chunked processes

AMP implements process chunking to make sure that long running tasks get split up,  and don’t lock up your page. By keeping big tasks split into bite sized versions, AMP keeps your site feeling responsive to every interaction. 

Sandboxes for everything else

If code from outside of AMP is needed, it has to run in its own iframe. By running that code in its own container, it can’t block the user from interacting with your page. That means that slow ads or code heavy video players won’t stop users from actually being able using your site.

Cumulative Layout Shift
Cumulative Layout Shift (CLS), helps you measure visual stability

You may have seen our recent deep dive into CLS on the AMP Blog. Web pages jumping around due to slow loading content, or oversized images and video leads to all sorts of real world user frustration today. That is why having a good CLS score is a critical part of a well built site. Google’s recommendation is that your CLS stays below 0.1. This is a bit more complex of a measurement than the other Core Web Vitals, so I encourage you to read the documentation to get a better understanding. The key thing to understand is that a low CLS means that what your user sees is a stable and predictable, not jumping around.

CLS is another area where AMP really shines. It’s been built from the ground up to avoid the most common pitfalls of sites that score poorly on CLS. It has a number of rules in place that help you keep this number low, including: 

Statically-sized layout system

AMP’s layout system is built on the goal that it be able to infer the size of resources before it downloads them. For example, AMP requires any images, video, iframes – anything other than text, to be loaded via built-in components, which requires developers to tell the browser the height and width of these resources. 

<amp-img height="200" width="400" src=...

By making sure these attributes are included before the content is downloaded, AMP can make sure the browser can lay out the page how it will look once the images are loaded. Without them, the browser will inevitably need to shift the layout as it downloads and determines how much room is needed for each element.

Interaction required for dynamic content

All updates to a page that potentially cause a re-layout need to be triggered by a user interaction. You can’t have a widget pop up right before the user taps on something. By restricting updates to happen in response to interactions, your users are a lot less likely to get an unpleasant surprise.

Efficient font loading

Many websites use external fonts to style their page. Having to download an external CSS file, find the reference, and download the font can easily cause jittery, jumpy page loads and can lead to a disorienting experience for users. AMP mitigates this by requiring all CSS to be inline, at the top of web site’s source code. Any fonts are quickly discovered and downloaded. Additionally, the async loading of JavaScript mentioned in our FID exploration means that JavaScript also being downloaded won’t block the browser from handling custom fonts. 

Largest Contentful Paint
Largest Contentful Paint (LCP), helps you monitor the perceived loading speed

When a user loads your page, they can’t see network callbacks or other performance indicators. They just see the visual output, or lack of it. LCP measures when the largest element was rendered. Measuring when LCP occurs will give you a lot of insight into just how fast your page actually feels to your users. That is why LCP is such an important metric. The recommendation from is for LCP to occur within 2500 milliseconds at the 75th percentile. 

AMP has a number of optimizations in place to make your Largest Contentful Paint happen as fast as possible, including:

Intelligent resource loading

AMP’s goal has always been to feel instantaneous. One of many things it does to achieve this is to make sure images and ads are only initially downloaded when they are above the fold, or if the user is likely to quickly scroll to them. By limiting the amount of resources being fetched when a page is loaded, AMP can make sure that it is prioritizing the content that users will actually be viewed.  The result is a site that feels faster to your users.

Preloading and prerendering

When AMP pages are hosted on an AMP cache, a number of optimizations are added to the page to make sure that it is as fast as possible, like preloading the content. So by the time a user usually taps on a prerendered AMP page, the browser has already downloaded and rendered the entire thing — it just feels instant.

Pushing your AMP pages further

So far, we have just looked at what AMP does out of the box. However, there are a few development practices that our team believes to be essential to a great user experience that just can’t be implemented at runtime. While we try very hard to make AMP perform well beyond the expectations set out by the Core Web Vitals, it is still possible to fall short. To push AMP that much further, there are a number of additional optimizations you can perform yourself. In our research, we have found that developers have headroom to further optimize how they serve their AMP pages. The most common opportunities include:

Addressing slow server response times

If your server is slow, then almost everything will be slow. AMP caches help optimize delivery, like a CDN, but nearly all AMP sites have some traffic outside of an AMP cache. That means making sure your server is fast and responsive is essential to Core Web Vitals success.

Avoid using oversized images

For your site to be as fast as possible, you should avoid using images that are larger than they will be displayed on the website. Websites that load unoptimized images often increase the download size by hundreds of kilobytes, which can directly hurt their LCP results in Core Web Vitals. Make sure your users’ time and bandwidth are being respected by optimizing the images on your AMP origin.

AMP caches will optimize your code to avoid these types of issues, but keep in mind that the optimizations are only performed on caches. Anyone that visits your site directly, whether through a link shared on social media or just directly navigating to your site, won’t get the same experience. In order to ensure that you are getting great Core Web Vitals scores for all your users, it is very important to optimize your site at the origin! 

Tools to make AMP even better

The AMP team provides a number of open source tools to optimize your site. 

AMP Optimizer

The AMP Optimizer is a great option to improve AMP rendering performance. With features like server-side rendering and code minification, the AMP Optimizer is a great first step to making sure your site is loading fast.

AMP for WordPress Plugin

If you are on WordPress and interested in AMP, you should check out the official AMP plugin. Developed and maintained by the AMP team, it brings AMP content generation into WordPress, the WordPress way, and gives you a turnkey option to publish fast AMP pages, without requiring deep technical expertise in performance optimization!  The Official AMP plugin also provides developers with advanced tooling to help them with AMP development in WordPress.


Next, you just need to add a single line of code to turn any React site into an AMP site! Doing so automatically provides you with a wealth of performance optimizations like server side rendering (for a faster LCP), AMP Optimizer integration, and more. Check it  out!

The earlier you add performance optimizations, the better. By using tools like the ones mentioned above, you can make sure every user gets a fast and smooth experience, not just the ones who come to it via a cached page.


Web Vitals and Core Web Vitals are an important step forward in helping site owners understand where and how to improve user experience on the web. Not only will they help developers improve and maintain great user experiences today, but they will also keep developers informed about the latest performance expectations on the web as they are updated in the future. 

AMP Project contributors around the world are dedicated to ensuring site owners are getting the strongest performance guarantees when creating AMP pages. The AMP team continuously monitors how AMP pages are performing on the web, and regularly updates the AMP library with performance enhancements. And since AMP is an always up-to-date “evergreen” library, it means that without any added effort on your part, you and your users will always benefit from the latest AMP improvements. 

If you have any questions, please do let us know, otherwise make sure you are up-to-date with any of the other exciting changes coming to AMP by following us on Twitter, or signing up for our newsletter.

Written by Patrick Kettner, Developer Cheerleader, The AMP Project, Google

Creating accessible sites with AMP


The open web is powerful due to its ability to give everyone access to the same information. This means the Web needs to be designed to work for all people regardless of their location, hardware preferences, language, or abilities. AMP invests in this work through the UI and Accessibility Working Group with the goal to ensure that all AMP experiences are WCAG AA compliant by default. This means that AMP doesn’t just make it easy for you to create accessible sites, it goes one step further by making sure creating an inaccessible experience is not the default outcome.

This blog highlights some of the work that the AMP Project has put into creating accessible components and some key principles and tools that developers should keep top of mind as they create web experiences.

Enabling accessible sites

Accessibility is an important early consideration when designing AMP components. Our Design Reviews and Intent to Implement process focus on making sure that the components we release do not exclude people with varying accessibility needs. This results in AMP enabling you to create pages that meet the W3C WCAG 2.0, Level A and AA guidelines which are an important part of laws with accessibility considerations internationally. 

However, like any other framework, while AMP does allow you to create accessible experiences  and offers nudges to do so, we can’t enforce that all websites using AMP are meeting WCAG guidance. For example, while <amp-img> allows you to specify an alternate text, we don’t enforce that all images have alternate text; even if we did, we couldn’t enforce that the string provided was actually a description of the image without running extensive Machine Learning models.

How we reduce developer effort

Below is just some of the heavy lifting that the team has done to make the commonly used AMP components and actions accessible by default. 

  • <amp-sidebar>: Focus management was top of mind for the team as it implemented <amp-sidebar>. This is why <amp-sidebar> moves focus to the sidebar when opened and moves focus to the opener automatically when closed. It also provides a focusable “close” modal for users interacting with the component via a screen reader.
  • <amp-carousel>: For <amp-carousel> version 0.2, the next and previous buttons always announce the current slide and the total number of slides when being accessed by a screen reader. 
  • <amp-list>: By default, <amp-list> adds a list ARIA role to the list element and a listitem role to item elements rendered via the template. If the list element or any of its children are not focusable, or “tabbable” (accessible by keyboard keys such as the a and button elements or any elements with a positive tabindex), a tabindex of 0 will be added by default to the list item. This makes them explicitly accessible via screen reader. 
  • <amp-autocomplete>: The <amp-autocomplete> component will annotate its generated suggestions to announce that the input field will display suggestions and fully supports navigating through them and selecting them via keyboard. When suggestions are available, the user can use `Up` and `Down` arrow key navigation to visually highlight completed inputs, or for screen readers, to read them aloud.

What we intend to do in the future

Since accessibility is a top priority for the UI and Accessibility Working Group we plan to continuously invest in improving AMP’s default accessibility in the future. Below are a few themes we intend to work on:

  • Improve our contribution documentation by adding guidance on accessibility testing that needs to be done by anyone contributing components.
  • Improve AMP component documentation to clearly document the accessibility features the component gets right and what added work the developers need to do themselves (such as captioning all videos on the page).

Accessibility resources that the AMP team finds useful

To ensure that your sites are meeting WCAG AA guidelines, we suggest using the following tools to automate your testing. 

  • axe-core: An accessibility testing engine for websites that integrates with any existing test environment so you can automate accessibility testing alongside regular functional testing.
  • WAVE: Tools for facilitating web accessibility evaluation by providing a visual representation of accessibility issues within the page. 
  • Lighthouse CLI: Chrome Lighthouse builds on axe-core to publish a report on how accessible a site is. 
  • Other Web Accessibility Evaluation Tools suggested by the W3C here.

However, automated tools can’t always catch all issues, and the best recourse is to have a developer with understanding of the WCAG guidelines review your markup and CSS to ensure that best practices are being utilized.

As always, please let us know if you have any issues or feature requests especially in the accessibility space.

Posted by Naina Raisinghani, Product Manager, AMP Project

Web Stories, powered by AMP


In the two years since the AMP project brought the story format to the web, we have seen many publishers adopt the format to tell compelling, visually-rich stories. From VICE’s story on the Isle of Dogs to Globo’s coverage of cars of the future, the rich, full screen, tappable story experience continues to resonate with readers around the world. We especially love how publishers like NDTV are showcasing stories in new innovative sections of their main web property. In parallel, tooling support for stories has greatly expanded and improved, making story authoring available to everyone, especially those who want to create without needing to think about code.

Given this expanding universe of creators and consumers, it is time to transition the stories name from AMP (which continues to be the underlying technology for a fast, consistent and reliable user experience) to the web, where creators and users will experience stories. Moving forward, we’ll refer to the format simply as Web Stories. Web Stories live on the web, and continue to allow publishers or creators to control their content- just like any other web page.

The AMP team broadly, folks at Google and publishers we’ve spoken to are excited about the future of the Web Stories format. Over the coming months, we will share many more highlights of publishers using the Web Story format, as well as guides to easily creating stories with new tools coming online. 

Now is a great time to give crafting Web Stories a shot. You can try one of these easy to use drag and drop authoring tools, or dive deeper into more technical documentation at And, of course, if you have had a great experience with Web Stories, please share with us! We are always eager to hear your feedback as creators and readers.

Posted by Varun Rao, Web Stories Product Manager, Google

Introducing the fastest and most user-friendly content encryption


Stuck between keeping content secure and providing a great user experience? The debate is over! We’re introducing a new type of premium experience! Client-side content encryption is a fast and user-friendly solution to protect and serve premium content. All while providing the same level of security as server-side validation!

What’s the problem?

A server-side paywall process may look something like this:

The user lands on a page for subscribers only. 

The page asks the user for the login credentials then sends them to the server.

The user waits…

The server returns the premium content to a subscriber, 

or a paywall for non-subscribers, by refreshing the current page. 

AMP is all about speed, portability, and user happiness. However, server-side validation can cause a virtual detour. Users at the edge of their seat are dying to dive into breaking news and making this round trip can cost double the data for the same amount of content! Not to mention, users will drop off if they have to wait too long or if the process becomes too tedious.

Publishers often take a chance and aim for a more user-friendly experience by hiding content with CSS. But this comes as a cost! Savvier non-subscribers can break through these defences and access content, for free. 

So, how do we get the best of both worlds?

Get the solution!

The folks at AMP and Google created a new protocol to streamline the user’s experience and secure the publisher’s content. 

Client-side content encryption serves protected premium content before authenticating the user. This protocol uses a combination of asymmetric and symmetric-key cryptography to serve encrypted content. After verifying the user, it’s decrypted all on the client-side. Additionally, AMP handles all the heavy-lifting of encrypting and decrypting. All content is easily indexed by Google and ready to serve from its AMP cache, all while providing the same level of security!  

This is the most user-friendly premium content protection that doesn’t compromise security or speed. Learn how to implement this solution by reading Protect your subscription content with client-side encryption.

Written by Crystal Lambert and Elijah Soria
Images by Chen Shay

Introducing Code-Fi, the AMP code-from-home music mix

Developer Experience

The last month and a half have been hard for everyone around the world. As the developer community continues coding away from home, the AMP outreach team wanted to share something we put together to hopefully improve your coding experience. Introducing Code-Fi, our carefully curated mix of relaxing beats to code to. 

If you’ve never heard of Lo-Fi music before, it’s a genre of music that has become increasingly popular on YouTube in the last few years, and especially in the last month. Lo-Fi mixes are often used as relaxing ambient music that can be left open on the side while you work on a project, or played in the background at the end of a long day to unwind. However you use it, we hope you are staying as productive and relaxed as the AMP Code-Fi girl featured in our video!

Special shout out and thank you to AMP contributor Aaron Turner, who produced many of the songs in the mix, as well as put together this awesome mix of Lo-Fi tracks. Check out the video on YouTube to see the other artists featured. 

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

How AWeber makes AMP for Email Powerfully-Simple for Small Businesses


Editor’s Note: the following guest post was written by Dave Stys, Technical Product Manager, Email Delivery at AWeber

AWeber is a market leader of small business email marketing solutions. Founded in 1998, AWeber has over 20 years of proven success helping more than one million customers around the world reliably connect with their prospects and customers through powerfully-simple email marketing software and award-winning support.

AWeber is always on the cutting edge of email technology. That’s why we believe AMP for Email is going to change the way people connect and interact with email. So we made it a priority to make the power of AMP for Email accessible to small businesses — regardless of their technical abilities. 

After introducing AMP for Email technology to customers in July 2019, we released an AMP-powered image carousel into our message editor — making it powerfully-simple for small businesses and their marketing teams to use an AMP-powered element in their email messages.

In fact, AWeber uses AMP for Email technology consistently in its own marketing efforts. 

In the past year, we’ve creatively incorporated AMP-powered elements into our blog digest newsletter, FWD: Thinking, to create stronger interactions with subscribers. Through AMP-powered quizzes, polls, feedback forms, sentiment widgets and image carousels, we’ve consistently delighted customers and built stronger relationships. 

Quizzes and Polls

AMP-powered quizzes and polls allow subscribers to test their knowledge and share their opinions without leaving their inbox. Once subscribers click on an answer, they are automatically given the breakdown of subscribers who chose each answer. We share the complete results in the following week’s edition of FWD: Thinking.

Feedback Forms

With AMP-powered feedback forms, our subscribers can submit thoughts and opinions to us within the email itself. This eliminates the barrier of having to open a survey from another tab to share their feedback. We want to hear about their biggest pain points, as it lets us act more quickly to create educational content and product features our customers need.

Sentiment Widgets

Similarly, interactive sentiment widgets let us check in with our audience to see if we’re providing valuable content or not. With AMP for Email technology, we elevated our sentiment widget to include a dynamic form within our messages — which helps us understand why respondents reacted the way they did.

Image Carousels

Finally, our AMP-powered image carousel lets us incorporate a number of images or GIFs in an email without taking up too much space or visually-overloading our audience.


We first included a poll in our newsletter in October 2019. However, over the last five months, engagement on AMP for Email elements in our newsletter has skyrocketed over 225%. In fact, in response to one of the dynamic feedback forms, a subscriber said:

I have a question about this form in the email…Does it submit? What wizardry is this?”

As AMP for Email becomes more and more prevalent over time, subscribers will come to expect dynamic and interactive content in their emails. It will become the norm not to open a new tab to RSVP to an event, provide feedback or take a survey. Subscribers will want to take action in their inbox. And those who can provide that opportunity will delight their subscribers and be ahead of the curve. 

AWeber is the first small business email service provider to support AMP for Email technology for users – and in a powerfully-simple way that doesn’t require technical expertise. As you have read, we’ve experienced the impact of AMP for Email firsthand, and we want our customers to be able to access it as well. 

To learn more about how AWeber is using AMP for Email, sign up for AWeber’s newsletter, FWD: Thinking.