Debunking Common AMP Myths

Ecommerce, Websites

AMP is a great and easy way to build very fast sites. Since its launch in 2015, AMP has grown to power billions of pages across the web from tens of millions of domains. We’ve seen many examples of businesses in both the publishing and e-commerce spaces see success with implementing AMP on their websites. As the AMP project has grown, we have noticed a number of misconceptions & myths have arisen — so we thought we would take this opportunity to bust some of the most common myths about AMP.

MYTH: AMP is exclusively a Google project.
FACT: AMP is an open source initiative led by Google along with other companies and members of the web community.

AMP developers, companies and individual contributors participate in the development of this project: Over the last 3 years, AMP received contributions from 850+ contributors, 78% of whom were employed by companies other than Google, such as Twitter, Pinterest, Yahoo, Bing, and eBay. AMP moved to a new governance model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users, and representation from companies such as Twitter, Microsoft, Pinterest, The NY Times, Washington Post, AliExpress and many others.

MYTH: AMP only works from
FACT: AMP pages are accessible across the web including any distribution platform and device.

Users can access AMP pages via links on distribution platforms (e.g., search engines) or sites. Some platforms (e.g., Google, Bing, LinkedIn, Twitter, Yahoo JP, Baidu and more ) will always serve AMP pages by default on mobile, when available. Some platforms (e.g.,, take an extra step to cache your content for a much faster user experience.

MYTH: AMP is only for mobile.
FACT: AMP is designed with responsiveness in mind, to work across all screen sizes.

AMP is now just AMP, and does not stand for Accelerated Mobile Pages anymore. AMP isn’t just for mobile, it not only works across many device types including desktop and tablet but comes with super handy responsive design features. AMP is designed to be mobile friendly, and with slow hardware and high latency connections, the boost you get with AMP on smartphones is going to be felt a lot stronger than on desktops. It should also be understood that some features for third-party platforms (e.g., Google’s Top Stories carousel) may only be designed for the mobile experience. For more information, see this article.

MYTH: Every AMP page has to also have a non-AMP version.
FACT: An AMP page can be associated with a non-AMP version, but it’s not a requirement.

In some cases, you might want to have both a non-AMP and an AMP version of the same page, especially during the early phases of your AMP migration when you might want to also support testing AMP and non-AMP. But this is not a requirement and you don’t need to maintain two versions of the same content if you think AMP is the right solution for your business. You can choose to have one page, and that page could be an AMP page. This means lower maintenance costs to build, maintain, and monitor a single version of each document (as opposed to building both a non-AMP and paired AMP page). More details here.

MYTH: AMP landing pages are usually difficult to build.
FACT: It typically takes less than a week to build AMP landing pages for the majority of page types and use cases.

80% of development teams we contacted said they built AMP Landing Pages in less than a week. Having said that, AMP development effort varies on the page type. Some AMP pages can be built within a day, others take longer. Check out for some free AMP templates to reduce your development time even further.

MYTH: AMP is only for publishers or static websites.
FACT: More than 60% of Google Search clicks to AMP pages go to non-news sites.

AMP is built thanks to a deep collaboration with thousands of developers, publishers and websites, distribution platforms and tech companies. When AMP first launched, it was initially adopted by publishers but now advertisers and e-commerce companies are also leveraging AMP to gain speed benefits. Read some of the success stories on our site.

MYTH: AMP doesn’t support interactive experiences.
FACT: AMP components now enable design customization and interactive experiences.

When AMP first launched, it had limitations to visual design. As the AMP project has grown thanks to the collaboration of the open source community, new components have been built that allow companies to do design customization and create interactivity. Today, most interactive experiences are supported:

  • Rich Media: there are ever increasing AMP components and anyone can contribute if something is missing.
  • Third-Party (3P) integrations: there are many available now and growing.

Companies such as BMWAliExpress and Rep from La Repubblica have been able to build great interactive experiences on AMP, with some using AMP for the majority of their site pages.

MYTH: AMP is not capable of supporting e-commerce websites.
FACT: AMP is a natural fit for e-commerce because AMP makes web pages fast, and fast pages help with purchase conversions.

When AMP first launched, it was initially adopted by publishers. As the AMP project has grown, new components have been built that allow brands to create interactive experiences. We are excited by the speed with which the internet is adopting and extending the AMP platform, and AMP can be used to build a fast, beautiful e-commerce experiences. For more details, check “Getting started with AMP for e-commerce” and “E-commerce At The Speed of AMP” blog posts.  

MYTH: It’s not possible to serve fresh content on AMP Pages.
FACT: There are many options to keep content on AMP pages up to date.

You can serve fresh content on AMP either relying on the default AMP Cache mechanism (stale-while-revalidate), using the update cache functionality, or using dynamic components (like amp-list). Many big e-commerce companies have demonstrated great success when implementation is planned properly.

MYTH: AMP is not secure/private enough.
FACT: The AMP framework is built to preserve privacy and ensure data security.

AMP landing pages are often served from the Google AMP Cache, which simply caches a version of your AMP landing page for purposes of validating AMP documents and for providing reliable, fast delivery. The Google AMP Cache as well as AMP JavaScript are served from cookieless domains that do not track users in any way. Additionally, AMP has a security review process that is routinely used when launching new AMP components. For further reading we recommend this blog post “Privacy and user choice in AMP’s software architecture”.

MYTH: AMP pages don’t convert as well as non-AMP pages.
FACT: Properly optimized AMP pages often perform better than their non-AMP equivalents.

Many advertisers and publishers have seen success with AMP as documented on A study from Forrester found that a site implementing AMP could expect 20% increase in sales conversion rate on AMP pages, 10% year-over-year increase in AMP site traffic, and 60% increase in pages per visit. There are a few reasons why an AMP page might appear to perform less well than an non-AMP page. If you are seeing poor performance, these are a few areas to explore:

  • Measurement and tracking issues: Make sure you’ve setup analytics on your AMP page using the following two setup guides.
  • Inconsistent landing pages: If AMP page looks different from non-AMP page, it can affect conversion rates. Landing pages should be identical both in appearance and in function in order to accurately assess AMP performance. Also make sure you offer user-friendly landing pages.

You can check this blog post for the things to keep in mind when testing and evaluating AMP.

Posted by Cemal Buyukgokcesu, Global Product Lead, Mobile Web, Google

Privacy-preserving instant loading for all web content

Web Standards

In this second post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of instant loading. If you haven’t read yesterday’s post, we’d suggest to hop over there before reading this.

So what is privacy-preserving instant loading? It can be summarized as:

  • Instant loading means link navigations work instantly without any perceivable wait time.
  • In general that means they work without going to the network, because the network may be slow.
  • But not going to the network when the user clicks means to request the page some time before the user really initiated the navigation.
  • This may leak sensitive information to the page, such as that the user is interested in it, without user consent.
  • Privacy-preserving instant loading is instant loading where this information leak does not happen.

For more on this topic, see our post on privacy and user choice in AMP’s software architecture.

Below we describe a set of changes that combined enable content sharing websites, social media platforms, and search engines, such as Google Search, to provide privacy-preserving instant loading for web content that is not based on AMP.

After an extensive process where both AMP and Chrome teams identified and assessed potential solutions, encouraged by W3C TAG’s recommendation, Chrome’s web platform team eventually convinced us to explore the emerging Web Packaging standard and its component Signed Exchanges (SXG), and further invest in its standardization and implementation. SXGs help with privacy-preserving instant loading by allowing the referring site (such as the search engine) to load a resource from a trusted server without leaking any additional information to a third-party. Then, once the user navigated to the SXG, everything behaves just like any other web navigation (except for the faster load).

SXG support has recently landed in the stable version of Chrome, but is not yet available in non-Chromium based browsers. SXGs are a big step for the web platform: They disentangle attribution (who created a piece of content) from initial delivery (how is the initial view of the content delivered to the user), and guarantee content integrity (the content distributor cannot change it). While this creates exciting new opportunities like a more decentralized web, it also creates new security challenges that need to be worked through diligently.

On top of SXG support, we’ve worked with Igalia on making prefetching available across browsers. While <link rel=prefetch> had been specified for a while and widely used, it wasn’t available in browsers like Safari because of incompatibilities with double-key caches. The Chrome team proposed and discussed a change that makes prefetching compatible with double-keying, and Igalia’s patch just landed in WebKit.

Additionally, the Chrome team worked with the community on clarifying the spec for nested prefetches, i.e. when a prefetched resource schedules additional sub-resources to be downloaded. A Chromium contributor subsequently added support to preload for image srcsets after discussion with other w3c members and our partners at Igalia, who help us with implementing web features in WebKit, have recently landed similar patches in WebKit.


This was part 2 in our series of contributing lessons learned from AMP to the whole web. We’ve now discussed how to measure performance at scale and how to enable instant loading for web content. In the next post in the series we’ll talk about ideas for how to innovate on the concept of navigation.

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

A year into contributing back lessons learned from AMP to the whole web

Web Standards

In March of 2018 we wrote about our effort to contribute back the things we learned from AMP for the benefit of all web developers by addressing gaps in the web platform. In this work we’ve collaborated with the Google Chrome team, Igalia, who is helping us with implementation work in WebKit, and, of course, the wider web standards community. We’ve also learned a lot from the community and have seen a lot of exciting work that we can’t wait to apply. This is an update on how that effort is going.

Our work has focused on bringing the benefits that AMP implemented on the application layer to the whole web platform (AMP or otherwise):

  • Measuring performance and user experience: Make it possible to objectively measure high load performance and certain UX properties, such as a stable loading experience without content that is shifting around as it loads.
  • Privacy-preserving instant loading: Allow the preloading of web content, before a user clicks, without leaking the user’s interest in the page to the page author until the user navigates.
  • Innovation in navigation: Navigation from one web page to another through means other than the traditional click. E.g. by swiping through a carousel or scrolling from one article to another one.
  • Guardrails: Provide a mechanism for development teams to avoid the use of certain legacy features of the web platform that are harmful to UX. Give development teams  similar control over the behavior of third-party code.

We’ve made significant progress distilling our original wide-ranging ideas and worked with the web community to turn them into concrete standard proposals. This is a lot to go through, so we’ll split things up into a series of posts starting with the topics Measuring performance and user experience and Guardrails today.

Measuring performance and user experience

The AMP team often gets the question: Why don’t you just measure whether a page is fast instead of relying on AMP? And we agree, that is a good question.

One of the big changes in the web space since AMP was created is that there are now tools like the Chrome User Experience Report, which do, in theory, provide a way to get performance data for most sites on the web. Looking at this further we realized, however, that the existing metrics are insufficient to really make statements about the desirable user experience properties of web pages.

Legacy metrics like onload aren’t great proxies for user-perceived performance. Pages can both appear loaded long before onload fires and can appear NOT to have loaded long after onload fires.

One modern metric, First Contentful Paint (FCP), is the only currently available candidate metric for measuring perceived performance at scale. Unfortunately, while good user experiences always have a good FCP, having a good FCP is insufficient to really know whether a page is fast. FCP should probably have been called First Not-Completely-Trivial Paint because it is clear that users would in many instances not consider a page to be sufficiently rendered at the time of its FCP. For example, a loading indicator would trigger FCP, but the user wouldn’t be happy at this stage.

For these reasons we invested in defining additional metrics that would paint a more holistic image of user perceived performance. The two metrics currently under discussion are Largest Contentful Paint (LCP, name subject to change), which fires when the largest element of text or image on a page has painted, and Layout Stability, which is an indicator for how stable the layout is during page load. We’re hoping that these metrics, together with First Input Delay, which is further along in standardization, would allow one to say with reasonable confidence whether a page is fast and well-behaved from a user point of view.

An example of a page doing badly on the layout stability metric.


AMP introduced the AMP validator to ensure that documents complied with a range of best practices and to give helpful error messages when they didn’t. Based on earlier work by Tim Kadlec and Yoav Weiss on the Content Performance Policy idea, the notion of Feature Policies was developed through discussions with the web community. They provide both a way to turn off harmful legacy features, such as synchronous XHR, and to report violations of best practices, such as loading images that are much bigger than necessary, to the development team of a website.

A whole range of Feature Policies are in the works now covering many aspects of web development. One interesting aspect for Feature Policies that while wide browser support is desirable for enforcement, for reporting only mode, where you get notified about issues with your website, partial browser support is often sufficient to solve the identified issues for users of all web browsers.


This ends part 1 of our series of posts on contributing back lessons learned from AMP to the whole web. Thanks to the whole web community for the amazing help in getting these standards proposal on track and the great feedback to make them much better than we could have ourselves!

Next up in this series of posts is Privacy-preserving instant loading and Innovation in navigation. They’ll be posted on this blog in the coming days.

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

Signed-Exchange: Solving the AMP URLs Display Problem

Signed Exchanges

Editor’s note: the below was originally posted on Medium by Sarang Khanna, Software Engineer, OYO

For an AMP Page at URL, your SEO users are probably seeing this — At OYO, we solved the much dreaded AMP-Cache URL display problem for good, without losing any AMP benefits!

As a fast and responsive web pattern, AMP has taken over the web. But a major concern about AMP pages is that whenever users land on the page from a Google search, the displayed URL is never the publisher’s original URL. This has been a topic of both discussion and concern till now. Signed-Exchange is something which can help you show your own domain in AMP page URLs, with all the AMP-Cache capabilities intact.

AMP URLs can now be the page’s original domain (notice the address-bar)


Prelude AMP enjoys caching benefits on Google’s Search pages. Opening an AMP page from Google Search Results (the ones with the symbol) shows a “pre-fetched” version of the page coming from Google’s own cache. Hence, it opens with lightning-fast speed, as there is absolutelyno document-fetch done over the network upon clicking. (Read: OYO’s starting steps with AMP)

The issue However, since the content is fetched from Google’s Cache Server rather than the Publisher’s actual server, the URL shown to the users for that page starts with something like,and is not the page’s actual URL.

Before the Fix: An AMP page opened from Google Search Results

This leaves chances of doubt about the authenticity of the page’s content for the end-user. However, now there is a way to solve this issue and show the page’s actual URL, even when it’s served from Google Cache.

The solution 

The solution resides in implementing Signed Exchange — which basically lets you “allow” third-parties (like AMP-Cache) to be able to serve your page’s content from their servers but the browser can show your domain and URL in the address bar.

What is Signed Exchange and how can it help? 

Signed Exchange (or “SXG”) is an emerging technology which provides a way to prove the authenticity of a web document. This can be used to determine a page’s original publisher, no matter where the document is served from.

A publisher can “sign” an HTTP request-response pair with their domain’s certificate. Thus generated signed-exchange can be served to browsers, similar to web pages! With it, the browser can safely show the publisher’s URL in the address bar because the signature proves that the content originally came from the publisher’s origin.

Simply put,

Signed-Exchange = A Web Page + Certificate of its Origin

This can allow us to improve AMP URLs. The idea here is to serve a signed-exchange for Google’s AMP crawler to cache, instead of a web document, when your AMP page is crawled.

Subsequently, now when a user will select your page from Google Search, the cached signed-exchange will be served from the AMP-Cache to the client’s browser . It will allow the browser to show the actual page URL (even though the page came from a Google Cache server).

(How HTTP Signed Exchange works to deliver better AMP URLs)

See it in action. 

Google has announced the support for Signed Exchanges in Chrome and has adopted it for the benefit of AMP on it’s search result pages. The current browser support is Chrome 73 and above.

So go ahead on Google, search an OYO city and look for the lighting-symboled AMP pages. Keep an eye on the address bar to see the magic of SXGs.

The following section explains how we enabled Signed-Exchange to have actual URLs displayed for the AMP pages being served from Google…

Implementing Signed-Exchange to show your own domain in AMP URLs. 

  1. Get a Digital Certificate for your domain
  2. Set-up a packager (signer) for your AMP pages (See deploy-amppackager-aws for help!)
  3. Proxy your AMP pages through the packager before serving them
  4. Profit!

1. Get a Digital Certificate for your domain

For signing the HTTP request-responses for AMP pages, you need to get a Digital Certificate issued for your domain.
Note: The private key must be ECDSA, curve secp256r1. And the certificate should have the CanSignHttpExchanges extension enabled for production use.

Psst! For testing purposes, you can use free certificates or self-signed certificates. For production use, DigiCert issues the certificate with the needed extension.

For reference, here is how to generate an EC P-256 key and a Certificate Signing Request (CSR) which you can submit to CA for signing:

## To generate a new EC P-256 private key
openssl ecparam -genkey -name secp256r1 | openssl ec -out privkey.pem
## Generate a CSR using the key:
openssl req -new -sha256 -key privkey.pem -nodes -out ec.csr -outform pem

Give the CSR to a CA who will issue you a new certificate for the private key. For SXGs, you will need the privkey.pem and the issued Certificate Chain, fullchain.pem.

2. Set-up a packager (signer) for your AMP pages

Next, you need to run a “Packager” server, something which will sign (or, “package”) the required pages using your certificate and it’s private key.

Thankfully, the AMP team has come-up with the amppackager tool, a Golang server for this purpose which anybody can use with minimal configurations (GitHub repo).

All you need to do is fetch the tool, provide your configurations (the path to your certificate, your domain name and the URLs to sign) and run it. On local machine, you can try it out with a demo request and it should serve a signed-exchange for your page!

AMPPackager Basics: By default, amppackager listens on port 8080. Suppose it is running on localhost:8080, it serves the signed-exchanges on URLs of this format:

localhost:8080/priv/doc/<Document's URL>

For example, the signed-exchange for (AMP Page) will be served at: 

It serves other resources like certificate information on the URLs of this format:

localhost:8080/amppkg/<Path to Resource>

Note: Productionising the amppackager tool is still very vague.
We have open-sourced a boilerplate deployer (GitHub: deploy-amppackager-aws), which can be used to deploy amppackager on AWS Elastic Beanstalk! Use it for reference on how we streamlined the flow and put it to good use on OYO production.

3. Proxy your AMP pages through the packager before serving them

Upto this point, we have an amppackager server running to sign our AMP page requests. Time to look into which pages need to go through the packager and under what conditions.

Let’s address the exact requirements here (for the amppackager tool):

  • All requests starting with /amppkg/ path should be forwarded to the amppackager server unmodified.
  • For AMP page requests having the AMP-Cache-Transform header present (Google Crawler will have it, to indicate that it accepts SXGs), rewrite the URL to prepend /priv/doc and forward the request to the amppackager.
  • While serving AMP pages, set the Vary response-header to AMP-Cache-Transform, Accept. (Google Crawler will look for this header before asking an SXG from you)

Here is an example for a frontend Nginx proxy with the amppackager running on an upstream server amp_pkgr:

### AMP Packager resources:

location /amppkg {
# to amppackager, unmodified
proxy_pass https://amp_pkgr;

### Pages which are AMP:

location ~* ^/(.*)/amp {

# check for the "AMP-Cache-Transform" header
# (which Google crawler requests will have)
# to selectively pass this request to amppacakger or
# your usual web server
if ( $http_AMP_Cache_Transform ) {
rewrite /(.*) /priv/doc/https://$host/$1 break;

# add "Vary" response-header for normally served AMP pages
# (responses from amppackager will already have the header)
add_header Vary 'AMP-Cache-Transform, Accept';

# proxy pass to your usual AMP pages' server
proxy_pass https://website_server;



  • It may take Google’s Crawler some days to cache your AMP pages as Signed-Exchanges.
  • Avoid proxying non-AMP pages to amppackager.
  • Don’t expose amp_pkg to the outside world; keep it within your internal network.
  • Set up your amppackager server to be scalable as well as secure. It is a machine that will probably hold your certificate and private key too.

Links to infinity and beyond 

Hope you’ll enjoy the journey from to as much as we did. Thanks for reading… Have a cookie!

AMP as your web framework

Developer Experience

Update (5/2/2019): Added a paragraph to clarify compatibility with other frameworks (to not suggest a zero-sum game), and removed some language on how AMP was misunderstood that wasn’t needed to get the point across.

Read a blog post comparing popular frameworks lately? Participated in a frontend tooling survey? I can almost guarantee that AMP was not on the list. Which strikes me as odd, considering the millions and millions of domains running it. So, how come?

Here’s the content of this blog post in super over-produced video form. You should watch this. Trust me. It’ll be worth it.

How we got here: HTML vs. JS Frameworks, perception as distribution format, and paired AMP

The first reason why AMP isn’t perceived as a framework is that AMP isn’t a JavaScript framework. It’s a framework written in JS, but the authoring language for you is HTML, so technically it’s an HTML framework. The idea of HTML Frameworks isn’t new but they’re still fairly rare, so they are often not considered a serious alternative.

The second reason is that many compare AMP to RSS, and the media positioned it as competitor to certain other big companies’ walled garden media formats. That narrative certainly didn’t help, and for what it’s worth, we, the AMP team, never loved that comparison (but we also did our part we did confuse people with complicated words such as runtime and AMPHTML format). Web pages are already a great distribution format, and AMP just improves upon it by accelerating delivery via AMP caches and by bundling the main content further, for instance by inlining CSS.

And third, most AMP sites today use Paired AMP, a technique we allow to connect an existing non-AMP webpage to an AMP equivalent. Look, Paired AMP can be useful because the initial investment is much lower: If I packed my bag and later realize I want to pack more stuff, I can just pack another one and travel with two, but it gets really annoying. The same is true for Paired AMP. It’s super hard to maintain both versions over time, and Paired AMP was never meant to be the end state. (That’s why we’re now calling it Transitional mode in AMP for WordPress).

From Accelerated Mobile Pages to AMP

Even our name has been a cause for confusion. I’ve been struggling to properly explain what AMP is for a while now, especially to those who are familiar with its long form: Accelerated Mobile Pages. The reality is that we’ve outlived our own name long ago:

  • AMP isn’t just accelerated, it comes with all sorts of built-in UX advantages (e.g. disallowing interstitials, enforcing a free main thread for smooth interactions).
  • AMP isn’t just for mobile, it not only works across many device types including Desktop and tablet but comes with super handy responsive design features
  • And AMP doesn’t just power pages anymore – you can now build ads, emails and stories with it.

So, what’s the solution? Easy: As announced by AMP’s tech lead Malte at AMP Conf, AMP is now just AMP, and does not stand for Accelerated Mobile Pages anymore (if you must have an expanded form, how about Awesome Magical Power).

From page to site: Going AMP First and using AMP as a service

We, the AMP team, want AMP to become a natural choice for modern web development of content websites, and for you to choose AMP as a framework because it genuinely makes you more productive. This represents our core mission this year, and we’ve rolled out our new site at (along with plenty of new content and beginner-friendly courses) to help you do it. So what do you get when you embrace AMP as your development framework (besides the obvious, like speed, UX, easy to use components)?

For starters, you’ll focus more on layout, style and content, and less on boilerplate code. Web development has gotten too hard, and it’s more important than ever to choose the right level of abstraction, with just the right amount of flexibility for your use case. We’ll worry about maintaining the JS for all components, and will ship backward compatible updates every two weeks. We call this way of lowering your maintenance burden “AMP as a Service” (watch Naina’s excellent talk on the topic).

You’ll now only maintain one version of each page by making your AMP canonical, or so-called “AMP first“, and that means your pages benefit from AMP’s performance and UX optimizations across Desktop, mobile and beyond.

Bento: Mix and match AMP components on non-AMP pages, interop with other frameworks

Watch the Bento announcement in What’s next in AMP from AMP Conf ’19.

AMP First doesn’t mean that strictly all pages of your site must be AMP – sometimes you might want maximum flexibility and distribution is not a big concern, like with a member-only area or complex shopping cart. In that case you could use vanilla JavaScript or another framework to power that part of the experience.

To then make it possible to re-use existing templates you’ve built with AMP components, we’re working on what we call Bento AMP, the ability to use AMP components in an “un-managed” way, without loading AMP’s main JS file (v0.js), and coexisting with other web components and frameworks on the same page.

This, along with frameworks like Next.js adding support to server side render AMP and amp-script, the ability to run custom JavaScript in a web worker, means AMP and other frameworks can co-exist peacefully and can make each other stronger, which we’re really excited about.

Accelerated development with support for JS and running AMP components outside AMP

Of course, it might not make sense for you to drop everything and reimplement your site in AMP today, and that’s OK! I just want you to know that we’ve grown up quite a bit, and when you set out to redesign or create something new, AMP is here to help you succeed.

With the dynamic state binding capabilities of amp-bind, the dynamic data fetching of amp-list and the ability to use custom JavaScript via amp-script, the possibilities for content sites are now endless. And with new open project governance in place, the future of AMP is open for everyone to shape – everyone who wants the web to continue to flourish.

Posted by Paul Bakaus, Developer Avocado, AMP

AMP Conf 2019: Successful web experiences for everyone

AMP Conf

Konnichiwa from Tokyo and our third annual AMP Conf! More than 500 developers are joining us over the next 2 days to hear from 50 speakers about how they’ve used AMP, what they’ve learned, and what’s coming next. With over 850 code contributors to the project and billions of AMP websites, the AMP team is more motivated than ever to build towards our vision of a strong user-first open web forever. And with a new governance model announced last year, leading voices across the web will ensure the project aims to meet the needs of both developers and users.

See all the announcements in the AMP Conf Keynote

AMP means great user experiences on the web

What’s in a name? When AMP started more than 3 years ago, Accelerated Mobile Pages fit pretty well. But AMP isn’t just accelerating webpage experiences anymore – it’s drives an overall superior user experience across the web. And mobile phones are just one of a myriad of supported devices AMP runs on, including desktop and tablets. Plus with immersive stories, dynamic emails, and better ads we are well beyond our original pages name.

Moving forward, The AMP Project will just be known as AMP – no acronym necessary, just a word that signifies speed and a great user experience across the web. You’ll see this reflected in our newly launched home for all things AMP,, where you’ll learn all there is to know about the types of experiences developers are using AMP to build.

The new home for all things AMP:

With documentation sections for websites, stories, emails and ads, developers can find what they need quickly. And we’ve strengthened the site’s resources as well, both importing the templates and examples that previously lived on and, and providing new assets like a use cases section with downloadable demos showcasing what’s possible with AMP.

Making AMP more capable

At its core, the web is comprised of 3 main elements: HTML, CSS and JavaScript. Since AMPs creation, developing with AMP only gave you access to HTML and CSS to ensure pages remained performant and secure. That’s changing now due to a technology called WorkerDOM, which brings full JavaScript integration to AMP.  The new amp-script component gives you the ability to run JavaScript from within an AMP document, all while ensuring that the experience remains safe and fast.

But JavaScript is now used in more ways than the client: One of the most popular ways to create AMP pages is through React server-side rendering. To support this use-case, we’re thrilled to share that Next.js, one of the most popular frameworks for React, is gaining first-class support for AMP. In fact is built entirely with AMP!

Additionally, AMP is now taking advantage of another web technology called web packaging that allows publishers to get the instant loading of AMP from their own domain. We’ve heard the feedback that AMP URLs from Google Search can be confusing or problematic, and last year began working on using signed exchanges to address this issue. We’re now excited to announce that Signed Exchange support is launching in Google Search, available to all users of browsers that support the new technology (currently Chromium-based browsers) and all websites that serve signed exchanges. This means you can now get instant loading for AMP on your own domain! See more details in this Google Webmaster Blog post or visit Cloudflare who recently announced that they are offering signed exchanges to all of its customers free of charge via a new product called AMP Real URL.

AMP as a Service

One of the differentiating features of AMP is that every day hundreds of open source contributors and dozens of full time engineers are working on making AMP better. In fact, because the AMP team and the open source community are constantly working on improvements that are shipped to all AMP pages via a CDN multiple times a month, you can think of “AMP as a Service”, modeled after the concept of software as a service.

This includes ways in which AMP is always improving your site directly with elements like image lightbox with swipe dismissal as default for many images, as well as a blurry image placeholder as an upgraded experience for images that take longer to load. Additionally AMP provides best-in-class and easy-to-integrate features like input masking, video docking or infinite scrolling for lists. And finally, we’re introducing a one-line ServiceWorker, an auto-configuring ServiceWorker that turns any AMP page into a PWA. It is preconfigured for AMP, so that it does all the right things for network resilience and improved speed out of the box, and like everything in AMP will become better over time.

Blurry image placeholder example

Driving ROI with Speed

We realize AMP’s vision is rooted in supporting the long term success of publishers and advertisers across the web. To this end we’ve seen strong recent success with AMPHTML ads, ads that are built with the underlying technology used on AMP pages. In particular, So-net, a Japanese DSP, has seen huge decreases in Ad Load time which resulted in major ad metrics improvements, such as a 34% CTR improvement. And leading Spanish newspaper EL PAÍS in partnership with Volkswagen ran an experiment combining AMP pages, AMPHTML ads and AMP landing pages, resulting in a sizable 76% conversion uplift. In other words, when AMP ensured the user-experience was great, each acquisition was 43% cheaper!

Online merchants are critical to the health and success of the web. Shopify, a platform that powers over 800,000 online businesses, supports AMP with their apps platform. Six of these apps, installed by more than 20.000 stores to date, provide great AMP versions of the Shopify storefront. Check out the full review of these Shopify apps in a recent blogpost.


We announced a developer preview for AMP Stories at last year’s AMP Conf. Stories are a new medium that was truly born on mobile, allowing users to have a visual content experience that feels native to their phone. And while many users experience story content within apps, we’ve spent much of the last year building out the capabilities of the AMP Stories format to take advantage of what is unique about a story product for the open web.  With AMP stories, publishers own their content, completely control the monetization, and design and distribute the content exactly as they like. Over the last year, we’ve seen many publishers create engaging content in the format. This week Washington Post contributor Lorenzo Tugnoli was awarded the Pulitzer Prize for Feature Photography for his rich and riveting photographs capturing the human toll of war in Yemen, which appeared in the paper as an AMP Story. The AMP Story presentation was so visually striking that it was submitted to the Pulitzer committee as the official document showcasing the photographs.

Over the past year, we’ve added many new features like page attachments, sidebars, and more robust support for a desktop experience. And story ads, with upcoming programmatic support as well as support for affiliate links provide greater monetization flexibility.

Sidebar menu in AMP stories

We also recognize that most creators of AMP Stories will prefer to use tools to create their stories rather than hand code them. We’re excited by the set of robust tools that are emerging. This includes MakeStories, an end-to-end WYSIWYG editor for making stories, that is now live to everyone at for free this week. Additionally Unfold, one of the top story creation tools with 17M downloads is integrating AMP Stories support as part of a new premium version of their product that will launch in June. And a new AMP plugin for WordPress is launching today in beta with a built-in WYSIWYG editor for AMP Stories. In the near future the stable version will enable all users of the AMP plugin to create their own stories with no additional plugin installation.

Ensuring great stories are visible and accessible is also a high priority for platforms like Google, which announced today that it is creating a dedicated block for Visual Stories on search result pages. Google is starting with story content in the travel space and plans to launch additional blocks for gaming, movies, TV, fashion, and more.

AMP story travel block on Google Search


Finally, we announced AMP for email at AMP Conf last year to bring the power of interactivity to email, and the format is now live and ready for business. AMP for email enables email senders to create dynamic, interactive content within an email, opening up a new world of possibilities without a user needing to leave their inbox. Dynamic mail was made available to Gmail and G Suite users recently, and we are excited to share that is exiting their beta and launching to all users this week. In addition, the AMP for email spec has engagement from other major email providers around the world including Yahoo Mail and  As each of these providers launches support, senders will scale the reach of their AMP emails to users.  And early adopters of AMP for email like OYO, India’s largest hospitality company, saw a 60% conversion lift for visitors coming via AMP emails since launch.


AMP has evolved well beyond its first step to help publishers speed up their content sites. With major improvements to make the library capable across websites, stories, ads and emails, AMP aims to empower developers to create great experiences across the web. The AMP team is as excited as we were on day one and remain committed to working towards our vision of a user-first open web forever.

Posted by Malte Ubl, Technical Steering Committee, AMP

Shopify Apps make AMP easy and effective for eCommerce


Online retailers are always looking for ways to exceed their customers’ expectations. With most online shopping now happening on mobile devices, it’s important for merchants to deliver fast, engaging experiences optimized for mobile. Because AMP guarantees consistently fast webpages, it’s becoming an increasingly popular framework for eCommerce.

Shopify Apps add functionality or features to Shopify stores, like plugins or extensions do to other platforms. Apps built to support AMP provide an easy way to launch a lightning fast, mobile optimized AMP version of a store that users love.

The best AMP Apps for Shopify are able to easily create many page types, including product, collection, home, and blog pages. They’re free or low cost, and come with reliable support. Some integrate with third party apps, meaning AMP versions of stores will not lose critical functionality such as product reviews. These Apps generate pages can be cached and served nearly instantly when accessed through Google Search.

The most popular AMP Apps have been installed thousands of times and have received 5 stars in 87% of user reviews. AMP by Shop Sheriff has great user reviews, and has been able to grow quickly because of their focus on user experience. “Merchants using our app, as well as their customers who get to experience the AMP pages, all love the experience,” said Shop Sheriff founder Stephen Gardner. “We’re extremely proud to have 98% 5-star reviews, and maintain a 5.0 average star rating on Shopify.”  

Out-of-the-box, top Shopify AMP apps provide beautiful eCommerce templates for product, category, home, blog pages, and more, which merchants can further customize. Above is a GIF of a user seamlessly customizing their AMP pages using the AMP App by AMPify Me.

Testing the AMP versions of these stores using PageSpeed Insights show industry-leading performance scores over 90, with pages being fully interactive in just seconds. Data show that users are more likely to bounce from a page that takes longer to load, and users view more pages on fast loading websites, leading to more engagement and higher conversion rates.

For the app creators, it’s all about using technology to improve retail experiences online. “We’re committed to building technology that makes it easy for retailers to succeed online,” said Jana Filipovic from AMPify Me, a leading AMP App. “Our customers, and even users of our free products, are able to drive increased engagement and conversion rates using AMP.” Their focus on great product and user experiences have enabled AMP by AMPifyMe to grow very quickly. Over 13,000 stores have installed their App since launch in May 2018!

Shopify noted in a recent blog post that AMP by Shop Sheriff and AMPifyMe were leaders in the category of successful apps that improve mobile performance. “By helping merchants take advantage of this mobile-first opportunity, these apps were able to find success on our app store.”

Top Shopify AMP apps have a WYSIWYG editor that enables merchants to customize the look and feel of AMP pages to deliver feature rich, lightning fast user experiences. Above is the editor from Shop Sheriff.

Google recently conducted a detailed review of the most popular AMP Apps for Shopify, analyzing the apps across 5 critical characteristics. If you’re a Shopify client considering AMP, consider these when choosing a provider:

  1. Price & Support – How much will the app cost at the service level that’s appropriate for you, and will you get quality support for that investment?
  2. Ease of Use – How much work is required to set up the AMP version of your shop? How intuitive is the app’s user interface?
  3. Quality of AMP pages – How good is the user experience on the AMP version of your shop?
  4. Integration with Google tools – How easy will it be to ensure the AMP versions of your pages are cached by Google and any issues are surfaced?
  5. Third party integrations – Which of your other apps can be integrated out-of-the-box? Which can be integrated with a little more work?

Apps provide an easy path for merchants to adopt AMP on Shopify, creating a lightning fast, mobile optimized version of their pages that can help meet users’ rising expectations. Check out our review on to see which AMP App might be best for your Shopify store.

Posted by Chris Sater, Web Product Partnerships, Google

AMP on the Times of India


Editor’s Note: The below post was originally posted on the AMP WordPress Plugin site by the Times of India.

Site performance and user experience matter to the Times of India, and therefore we keep tabs on new solutions and advanced technologies that allow us to make our website faster, more engaging, and more user-friendly. This is why we decided to evaluate the official AMP plugin for WordPress to leverage the performance and usability advantages that AMP enables. Our goal was to evaluate the plugin on some sections of our web presence, and then scaling it across other Times of India sites.

We started this project with  At the beginning of the evaluation we faced some expected challenges having to do with the need to make changes to the site to align it with AMP principles, such as CSS size constraints and the removal of 3P JS.  Some of the aspects that were tackled included the refactoring of certain components and widgets, such as the Social Share widget to implement them using AMP components,  replacing pop-ups with the AMP-lightbox component, implement tab panels using the amp-selector component, and other similar changes required to make the site compatible with AMP.  One important change was the replacement of all the Google Ad Manager/CTN ads on the site with AMP ads.

During the implementation process we took advantage of the available documentation on both AMP in general, and the AMP plugin in particular, and we interacted with AMP team to get their support in answering our questions and guiding us towards fixing all of the issues we encountered. Although the entire evaluation process took about two months, the actual implementation effort took us only about two weeks. And we are happy to report that the results were fantastic!

We are currently using version 1.0.2 of the official AMP plugin 1.0.2, since this and later versions allow us to make our entire site fully AMP compatible (i.e. AMP First). The impact on key metrics we are seeing after rolling out the new implementation was quite amazing:  a 59% improvement in page load time (11.40 secs before vs. 4.35 secs after), and early measurement data indicates the number of page views  increased by 4% . We expect this to go substantially higher as we continue to improve the experience.

The technical investment we made for evaluating a fine-tuned AMP implementation of our site setup was well worth it as it has made our pages much more user-friendly and faster. Furthermore, we are planning to scale it up across other websites in Times Internet wherever it is applicable.

Although making our site AMP compatible was a learning experience for us, the end results are rewarding and impressive, enabling a reduction in load time from 11.4 secs to 4.35 secs.

Puneet Walia: Technology head – TOI, GadgetsNow, eTimes & Mirror

Quick, Easy & Fast: 
Launching our first fully AMP WordPress site has yielded excellent results not only in terms of performance but also on ranking and revenue; we observed a spike in revenue traffic of about 4% during the first week.

Rudra Kasturi: Vice President, Organic Growth Head for Times Group Sites moves to!


It’s been over 2 years since the current version of launched, just before the very first AMP Conf in early 2017. Since then the AMP Project has grown a lot and launched entirely new applications of AMP on the web like emails and stories. Additionally AMP resources were scattered across multiple websites like and So we decided to bring everything together into something new, better organized and easier to use.

To bring all of AMP under a new home, we’re thrilled to announce! The all new will replace in order to provide developers (and their business counterparts) everything they need to know about AMP across all its various forms. And of course, it’s built entirely with AMP, using AMP optimizer to make the site load even faster when not served from a cache.

The all new homepage

On you’ll find information for all the applications of AMP- sorted by color across websites, stories, ads and email. Overall the documentation section was designed to make navigation as straightforward as possible. Guides and tutorials are sectioned by stages in the AMP developer workflow. This will give you the resources and confidence to build successful AMP sites at each step in your process!

Documentation across websites, stories, ads and emails

All of the existing resources, as well as the templates on have been migrated and integrated into various sections of We also have new sections like Use Cases, where you can find a gallery of different possibilities of creating with AMP. While this section only as a few items at the moment, it will continue to grow in the coming months.

The Use Cases section of

For a brief time we’ll be leaving up to allow for a smooth transition to the new site. However, in the near future we’ll be setting up redirects as we begin to turn down For now, we have banners on each site to indicate the upcoming change. The blog (what you’re reading now) has already moved to

Finally, just as the AMP Project is a community effort, we invite you to share your feedback on the site so we can make it the best it can be. We’ve created a feedback form linked from the bottom banner of every page so we can ensure to get your thoughts and issues if something needs fixing. As with before, is maintained on the docs repo of the AMP Project on Github, so everything is publicly viewable. You’re able to file Github issues there as well.

A big thanks to our friends at Jung von Matt TECH who have been working on this for many months. We’re excited to continue to evolve alongside the AMP Project and to show you bits of how we did it at AMP Conf in Tokyo next month.

Posted by the core maintainers of Paul Bakaus, Sebastian Benz, Crystal Lambert, Matt Ludwig

Guest Post: AMP Email


Editor’s note: The below was originally posted on by Greg Grothaus, Software Engineer, Google

Google just officially launched AMP Email, with support from other webmail providers. I work for Google on AMP and worked on some aspects of this project. I thought I’d add my own thoughts on the announcement. My opinions are my own and not those of my employer.

The press has focused on the user experiences in AMP Email. This makes total sense, given the audience. My take, however, is that the more interesting development is the step towards standardizing of HTML Email. Let me explain.

Let’s take a step back and consider non-amp HTML email. The basic idea is that the sender provides two variants of each email using MIME type encoding. Here’s a simplified example:

From: "Senders Name" <>
To: "Recipient Name" <>
Content-Type: multipart/alternative; boundary="bdac7942f697eecfbdac7942f697eecf"

Content-type: text/plain;

Some text content.

Content-type: text/html;

Some bolded html content.


An email client is free to choose which of these 2 alternatives to display and more importantly how to render the bytes.

An email client is not itself a web browser, even if it runs within one. Allowing arbitrary HTML email to run with the full API of a web browser simply fails. The first thing most marketers would do is add a redirect to their own site the moment the email loads.

Simply mitigating redirects and similar is insufficient. The privacy of the user reading the email must be protected. In the case of Gmail and many other webmail clients, the client actively prevents the sender from learning the user’s IP or browser fingerprint. This is fundamentally different from how web browsing works, so browsers fail to provide protection. When browsing, your browser sends your IP address, browser name, and capabilities along to every page that you visit.

A webmail client must then contort it’s presentation of HTML, a language not designed with email in mind. Webmail clients only have two ways of doing so:

  1. Show only the text version of an email.
  2. Modify the HTML before delivery such that the resulting document is safe.

Webmail clients do both. In some cases, the client falls back to text. In most cases, it modifies the HTML.

This is typically called “HTML sanitization”. For some examples:

  • <script> tags removed completely.
  • Image URLs are rewritten to load the images from the webmail provider.
  • Some or all CSS is removed completely.

In many cases, the HTML gets horribly mangled and then shown to the user completely broken, but at least it does not violate the user’s privacy expectations.

A sender must ensure that the email sent will not arrive completely broken.

Each webmail provider sanitizes HTML emails slightly differently. In some cases, not so slightly. The rules for the sanitization are necessarily complex, as HTML is complex. As a result, the documentation describing these rules is often poor or even missing. It’s almost never the case that two email providers will treat the same email the same way.

Some references to support my point:

Webmail Rendering Explained: Why Preprocessors are the enemy:

“Most preprocessors err on the side of being overly restrictive and remove anything with even the slightest potential to affect the layout of their email client.”

Developing HTML Emails for Gmail: 12 Things You Must Know:

“Many email developers know how tricky it is to develop HTML emails for Gmail – it’s one of the more temperamental clients out there (although it’s no Outlook).”

Mailchimp: Testing Emails:

“If you’re a web designer, you’re probably used to testing web pages in a few different browsers, like Internet Explorer, Mozilla Firefox, and Safari. And you’re probably familiar with a few annoying inconsistencies between all the browsers, and you have a couple hacks to make things look right. For email design, multiply all that by ten. There are tons of email applications out there that you need to test on, and they all render HTML email in their own annoying ways.”

See Mailchimp’s Email Client CSS support matrix to get an idea of the mess you can expect if you want to write an HTML email.

Beyond documentation, none of the major webmail companies provide testing tools. This has resulted in a small industry of services that exist simply to help you test whether or not an HTML email will render correctly.  Try this query to get an idea: [html email testing tool]. These services work by maintaining accounts on major mail providers, automating test emails, reverse engineering the sanitization layers, and staying on top of changes.

AMP improves on some of these problems.

With AMP Email, there is a specification for an email sender to develop against. That specification is complicated and evolving, like the others. The documentation is incomplete, like the others.

What’s different about the AMP Email spec?

There is a single specification which multiple webmail companies are implementing. The announcement lists Gmail, Yahoo Mail,, and Mail.Ru. The list is incomplete, but is a solid start.

Open source tooling can validate an AMP Email. Developers get detailed error codes including line numbers and documentation links. The tooling can be run locally as an NPM library or online:

A screenshot of the AMP Validator showing an example AMP Email error.

If a developer meets the specification, the promise is that the email will be correctly rendered in every supporting html mail client using every modern browser. The spec and the web mail implementations continue to guarantee the privacy of the user reading the email.

That’s the punchline as I see it: AMP Email is a consistent format that “just works” for developers trying to send HTML email.

There are a few other concerns that have been raised, but I feel some of them are uninformed, while others may be valid:

This is a proprietary format

The specification is open-source and is just a subset of HTML, but it is managed by the governance of the AMP Project. Also note that in effect HTML Email is a set of proprietary formats. No web mail provider supports arbitrary HTML.

Email should be plain text

Perhaps. There is certainly an argument to be made here. I personally suspect that users may be making the wrong dichotomy here: not that HTML email is bad, but junk email is bad and junk email tends to use HTML formatting.

Furthermore, AMP HTML Email does not change the story. No mail provider that currently does not support HTML email also does support AMP HTML email.

HTML email usage seems to be increasing. Simply bolding text or adding an image to an email makes it HTML email, which can be a better experience for most users.

AMP HTML Email still includes a text fallback mime type for users who prefer it.

Yet another format

The concern here is that since not all email clients support AMP HTML email, this effectively added 1 new mime format in each email, rather than simplified anything. This is a valid concern. However, any proposal that requires all email providers to make a simultaneous change is doomed to fail. In the long run, hopefully this simplifies and improves the state of email.

Posted by by Greg Grothaus, Software Engineer, Google