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

Behind the Scenes: Deploying the AMP Runtime

Developer Experience

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

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

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

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

Understanding AMP Releases

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

Stable Channel

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

Beta Channel

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

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

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

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

Experimental Channel

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

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

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

Long Term Stable (LTS) Channel

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

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

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

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

Using the LTS Channel for a Webpage:

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

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

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

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

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

Nightly Channel

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

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

Release Schedule

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

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

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

A New Way to Self-host the AMP Runtime

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

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

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

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

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

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

* * *

With all these changes, we hope AMP releases are easier to understand, adopt, test, and deploy. Our thanks go out to you, the AMP development community, for your work and feedback. As always, please let us know if you have any issues or feature requests.

Posted by Naina Raisinghani and Raghu Simha, AMP Project

People Behind The Code: Simon Rønbøl’s AMP journey

Developer Experience

When AMP launched in 2015, Simon was starting his career with Online-Results A/S. He’d been researching AMP in his spare time to hone his skills and stay up-to-date with industry trends. Eventually, he learned enough to build a static site generator for AMP pages from his home. 

Having developed a passion for AMP, he brought his site generator into work to show its capabilities to the SEO team. This started a journey that transformed Online-Results A/S’ business offerings, and propelled Simon from intern to company partner in half a decade. 

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

Online-Results A/S is a remote digital arm – we analyze patterns in digital behavior and use those insights to build conversion-focused websites and marketing strategies for small & medium sized businesses. 

If you’re a company of 10-20 people that focuses on car repairs, you might not have the time or capacity to have a website developer on staff. We can build them easy websites that are intuitive, high-performing, and highly-convertible.

Loading time has always been a huge part of our offerings; we use the Page Speed Insights tool as a big motivator to sell our websites. When we saw that AMP loads instantly on Google Search we made the switch – we wanted to make our fast sites even faster. I give a lot of credit to my management team; after a couple of tests they were willing to throw a lot of time and resources behind making the switch. It’s really paid off.

Did integrating AMP present any challenges? 

No, it was really plug-and-play. Turning our static html sites into AMP sites was fast – optimizing them was the journey. 

We’d been using a bloated CMS up until that point; a massive infrastructure with constant performance bottlenecks. For the small sites we were building it was like shooting at birds with cannons! So I built a static site generator, then leveraged the AMP community to troubleshoot it. 

You mentioned optimizing AMP – do you have any examples? 

We never stop optimizing! Just last week I implemented CSS tree-shaking into the static site generator. Now we have an automatic way of going through every page, checking to see if the CSS is actually used on each individual site, and then stripping unused CSS away. 

How did AMP impact your business? 

The static site generator is at the core of how we use AMP. Every time a designer or developer comes up with a new idea, we go back to our HTML roots and get it built quickly. 

Back when we used the CMS, it’d take us hours to build something like a functional slider. Now we can just style it like we would any other HTML element. 

You don’t need to know JavaScript to be able to build – and that’s helped our designers bring their ideas to life in a quick, easy, and effective way. 

How has AMP helped you innovate? 

It’s made it very easy for us to create websites – one employee can go from a blank page to a completed site in three to four days now. That’s an optimized site with analytics, call tracking, the works.

Websites used to account for around 3% of our business, now it’s up to 20-25% of our total revenue. We made AMP really easy for our clients to understand. They see the little lightning bolt in Search results and instantly get that AMP’s speed adds credibility and trust to the sites we build.

What advice would you give to anyone considering AMP? 

If you’re a developer that wants to use AMP, I can’t recommend the Roadshows highly enough. You should hang out in the Slack chat too, that’s where you get a lot of inspiration. If it all comes crashing down on your first build, then there’s always someone there to help out! 

You should also embrace getting back to your roots. It’s easy to fall into the habit of throwing new plugins at each new issue, but we see the 50 kilobytes of CSS limit as an opportunity to express your creativity in new ways.  

In my opinion, you can’t build a bad AMP page. It won’t be valid AMP if it’s not high-functioning – so get in there and play with it. 

Has AMP helped you achieve any personal or professional goals? 

Well, I’m a partner now! It’s helped me massively, and throughout the journey I’ve been so supported. I’m just one guy, I can’t keep building and updating sliders for my entire life. But with AMP, I feel like I’ve got a global team of open source developers working together to create the best components possible.  

It’s been such a timesaver, which has helped me to focus on personal development. 

What excites you most about the future of AMP? 

I can’t wait to see it expand into AMP for Email and AMP Stories. I really want to see how AMP shakes up email. It has the potential to change everything. 

If you ask any developer, they hate working on emails. Coding an email is way too difficult! You have to use some 1998 standard, it’s just so annoying. So having an AMP email library will be incredibly exciting.  

Are you interested in mirroring Simon’s journey? Check out the resources on for everything you need to further your career with AMP.

Grow your AMP skills 

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

Announcing AMP Toolbox 1.0

Developer Experience, Websites

AMP Toolbox has been around for a while now, but I thought it’s a good idea to make a proper introduction now that we’ve reached the 1.0 milestone. In short, AMP Toolbox is a collection of command line tools and JS APIs to make it easier to successfully publish AMP pages. Each tool can be downloaded and used separately.

The 1.0 release includes two big updates:

  1. 1. A linter for AMP documents: AMP Linter reports errors and suspicious constructions such as missing or incorrectly sized images, missing CORS headers, or invalid metadata.
  2. Valid optimized AMP Support: the AMP Optimizer will now produce valid AMP, making it a lot easier to host optimized AMP pages. See the previous blog post on this for more details.

But there’s more cool stuff! Let’s take a closer look at what else is in AMP Toolbox.


First of all, there’s a command line interface available for most features included in AMP Toolbox. You can install it globally via NPM:

$ npm install @ampproject/toolbox-cli
$ amp help

or you can run a one off command using NPM’s built-in `npx` tool:

$ npx @ampproject/toolbox-cli help

AMP Linter

The brand-new toolbox-linter checks your AMP documents for common mistakes and best practices:

$ amp lint

PASS 1x1 images are specified by <amp-pixel>
WARN All <amp-img> have reasonable width and height
> []: actual ratio [1999/1140 = 1.75] does not match specified [16/9 = 1.77]
> []: actual ratio [3680/2314 = 1.59] does not match specified [16/9 = 1.77]
PASS Videos are under 4MB
PASS <amp-video><source/></amp-video> syntax is used for video
PASS Endpoints are accessible from cache
PASS Endpoints are accessible from origin
FAIL <meta charset> is the first <meta> tag
> <meta charset> not the first <meta> tag
PASS Runtime is preloaded

Or without installation:

$ npx @ampproject/toolbox-cli lint

AMP Linter’s SXG mode is invaluable when adding SXG support to your site:

$ amp lint -f sxg

PASS /amppkg/ is forwarded correctly
PASS application/signed-exchange content negotiation is correct
PASS dump-signedexchange -verify does not report errors
PASS vary header is correct

AMP Optimizer

AMP Optimizer is a tool to server-side enhance the rendering performance of AMP pages. AMP Optimizer implements AMP performance best practices and supports AMP server-side-rendering. These optimizations can result in up to 50% faster FCP times. 

You can play around with it via the CLI:

$ amp optimize
$ amp optimize file.html

However, for production, it’s better to integrate toolbox-optimizer as part of your build or rendering chain. There’s also an Express middleware available: amp-optimizer-express that will apply AMP server-side-rendering on the fly.

AMP Cache URLs

For testing, it’s a good idea to check whether an AMP page works on all AMP caches. Use toolbox-cache-url for translating origin URLs to the AMP Cache URL format.

$ amp curls

Or for a specific cache:

$ amp curls --cache=google

AMP Cache List

There’s also an API available to get a list of all official AMP Caches. This can be useful when implementing CORS in your backend:

const Caches = require('@ampproject/toolbox-cache-list');


Sometimes it’s necessary to quickly update or remove AMP documents from an AMP Cache. Using the CLI version of the AMP Update Cache API this becomes very easy: 

$ amp update-cache --privateKey /path/to/private-key.pem

Of course, there’s also an API version available as part of the toolbox-update-cache package.


Speaking of CORS, many AMP components, such as amp-list or amp-state, take advantage of remote endpoints by using CORS requests. Part of AMP toolbox is a connect/express middleware which will automatically add all CORS headers required by your AMP pages. Simply add the toolbox-cors middleware to your express application and you can forget about CORS when serving your AMP pages:

const express = require('express');
const ampCors = require('@ampproject/toolbox-cors');

const app = express();

// That's it!

AMP Validation Rules

In case you want to implement AMP specific code completion for your favorite text editor, take a look at amp-validator-rules: a javascript library for querying AMP validator rules. Here is a sample that will list all valid attributes for the amp-img element:

import validatorRules from '@ampproject/toolbox-validator-rules';
validatorRules.fetch().then(rules => {
  // Get all website specific tag rules ...
  const tags = rules.getTagsForFormat('AMP');
  // ...find the definition of the amp-img tag...
  const ampImg = tags.find(e => e.tagName === 'AMP-IMG');
  const ampImgAttrs = ampImg.attrs
    // ...filter global, layout and amp-bind attributes...
    .filter(e => !'[') && ! && !e.layout)
    // ...extract the name...
    .map(e =>
    // ...sort alphabetically...
  // ...and display result in the console.


AMP Toolbox aims to simplify common tasks either via command line or APIs. If you think there’s a piece of functionality missing please let us know!

Posted by Sebastian Benz, Developer Advocate, Google

Faster AMP on the origin: AMP + SSR =

Cache, Developer Experience

AMP now officially supports a technique called server-side rendering (SSR) which you can apply to your AMP pages to make them load even faster. Our tests show increases of up to a whopping 50% on the popular FCP metric. The Google AMP Cache has utilized this technique for a while, but now you can also use it on your own domain! Installing this extra optimization is especially important if you are using AMP for delivering your main site experience. Even if you are using what is called the “paired AMP setup” where you have AMP and non-AMP pages, this technique ensures optimal performance for your user if the AMP Cache isn’t used, such as by users using the Twitter app.

SSR is a technique for improving first-contentful-paint times (FCP) for frameworks rendering the page client-side such as React or Vue.js. The downside of client-side rendering is that all Javascript necessary to render the page needs to be downloaded first. This delays the time until users can see the actual content of the page. To alleviate this, both React and Vue.js support pre-rendering the DOM on the server on navigation requests. Rendering is then picked up by the client-side Javascript, a process called (re)hydration. Users will be able to see content much faster as a result. 

AMP SSR works by removing the AMP boilerplate code and rendering the page layout on the server. The AMP boilerplate code exists to prevent content jumps on page load. It hides the page content until the AMP framework has been downloaded and the page layout is established. As a consequence, AMP pages suffer from the same problem as other client-side frameworks: rendering is blocked until the Javascript has been downloaded. By removing the boilerplate code, AMP SSR results in 50% faster FCP times. Here is a diff comparing an AMP file with it’s SSR’d version (for a detailed explanation check out the official guide):

You can identify server-side rendered AMP pages via the transformed attribute in the html element:

<html amp transformed="self;v=1">

Sidenote: AMP caches set their own flag, for example, the Google AMP Cache adds:

<html amp transformed="google;v=1">

With this attribute being set, the validator treats SSR’d AMP as valid AMP. SSR’d AMP optimizations break the rules of the AMP spec, hence making the document invalid, which is why it’s necessary to indicate this case with this new flag. With the flag and the optimizations both being in place, the document is considered valid and you’re good to go.

If you want to learn more about AMP SSR, checkout the explainer video on the AMP channel or read the AMP SSR guide.

How to SSR AMP?

It doesn’t make sense to hand-write SSR’d AMP. Instead, use a tool to automatically transform your AMP files into a SSR’d version, like a compiler would. Ideally, this transformation takes place ahead of time, before a user requests a document. However you can also run it on demand (make sure to cache the result to avoid running the transformation over and over again). 

Currently, there are two tools available for AMP SSR:

  1. AMP Optimizer: a NodeJs library for producing optimized AMP. If your site is powered by Express, you may also be interested in the express middleware
  2. AMP Packager: a go command-line tool, usable in conjunction with serving signed exchanges.

Sidenote: these tools will not only perform SSR, but will also perform other optimizations such as preloading the AMP framework and re-ordering the head.

Next.js support

We are super excited that the latest Next.js 9 release supports AMP SSR out-of-the-box. Next.js 9 now renders optimized AMP by default for AMP-first and hybrid AMP pages. This makes Next.js a great choice for building AMP pages. 

What’s next?

We have two big things planned for the future:

1. The option to self-host the AMP framework (v0.js). Yes, you got that right, you’ll no longer have to download AMP from This will have two advantages: 

  • Faster time-to-interactive: downloading the AMP framework no longer requires establishing a second HTTPS connection to
  • Easier QA: you can control when you want to switch to a new AMP release.

It’s important to note though: for privacy reasons, AMP caches will re-write AMP script URLs to match the cache origin when serving a cached AMP page. 

2. WordPress integration: v1.3 upcoming release of the official AMP plugin will support AMP SSR out-of-the-box. 

AMP SSR is for everyone

If you publish AMP pages, you should publish server-side-rendered AMP pages. Similar to minifying your HTML or CSS, running AMP Optimizer or the Go transformers should be a normal part of your build / rendering chain. The improved rendering performance makes a big difference in FCP times, but more importantly, in the user experience.

Posted by Sebastian Benz, Developer Advocate, Google

AMP Contributor Summit 2019 Applications Now Open

Developer Experience, Events

Applications for the AMP Contributor Summit 2019 are now open!  If you have contributed to the AMP open source project–or want to start–please apply to attend today.

This year’s summit will take place in New York City on October 9 & 10, with an optional New Contributor Workshop / Hackathon Day on October 8.

The AMP Contributor Summit is our annual opportunity for the AMP open source community to meet face-to-face to discuss the latest in AMP and where AMP is going.  This technical summit consists of a mix of different formats, including talks, breakout sessions and many opportunities for informal conversations.

The day before the main summit kicks off, we’ll have an optional New Contributor Workshop / Hackathon day, with two different tracks depending on your experience:

  • If you haven’t contributed to AMP before or want a refresher, we’ll have a New Contributor Workshop with talks and codelabs to get you up to speed on how to contribute to AMP.
  • If you already have some experience contributing to AMP, we’ll have a Hackathon for people who want to have a fun, concentrated day of coding with others in the community to make AMP better.

100% of those who responded to a post-summit survey for last year’s AMP Contributor Summit said they’d recommend the event, and our goal is to make this summit even better.

Apply to attend the AMP Contributor Summit by July 22, 2019.  We’ll get back to all applicants soon after that.

All of the content for the summit comes from the community, including the talks!  Please help us craft the summit agenda by proposing a talk or letting us know what topics/speakers you’d suggest by August 15, 2019.  

If you have any questions, please reach out to ampcs2019-support at

We’re looking forward to seeing you in NYC in October!

Posted by Joey Rozier, member of AMP’s Outreach Working Group and Engineering Manager, Google

Learn web development with AMP!

Developer Experience, Websites

We’re excited to announce the release of our new courses that teach AMP. Appropriately, they’re called Web Development with AMP!

We think AMP is an excellent starting point for aspiring web developers. After all, AMP lets you create interactive websites without having to use JavaScript. If you know a bit of HTML and CSS, but haven’t yet learned JavaScript, you can use AMP to create interactive websites.

On the other hand, if you’re an experienced web developer, and you’re seeking a simpler way to build performant, well-behaved websites, these courses are for you too.

Finally, if you teach web development, these courses are free to use. For beginners, these AMP courses bridge the gap in a curriculum between HTML/CSS and JavaScript. Others can use the courses to pick up the principles of AMP quickly.

Web Development with AMP is divided into beginning, intermediate, and advanced courses. These are available in many forms:

What’s coming next?

  • Videos for the other two courses will appear later this summer.
  • We’ll also be providing compressed versions of these courses for developers who are either more experienced or impatient.


Posted by Ben Morss, Developer Advocate at Google

Introducing Cloudflare AMP Real URL

Developer Experience, Signed Exchanges

The following post was written by Zack Bloom, Director of Product and John Graham-Cumming, CTO at Cloudflare

Join us for a free webinar this week where we will cover how Cloudflare is helping its customers drive better results with AMP, and increasing conversions.

The promise of the AMP project was that it would make the web, and, in particular, the mobile web, much more pleasant to surf. The AMP framework was designed to make web pages load quickly, and place the focus on the user experience.

Initially, it was particularly aimed at publishers (such as news organizations) that wanted to provide the best, fastest web experience for readers catching up on news stories and in-depth articles while on the move. It later became valuable for any site which values their mobile performance including e-commerce stores, job boards, and media sites.

As well as the AMP HTML framework, AMP also made use of caches that store copies of AMP content close to end users so that they load as quickly as possible. Although this cache makes loading web pages much, much faster they introduce a problem: An AMP page served from Google’s cache has a URL starting with This can be confusing for end users.

Users have become used to looking at the navigation bar in a web browser to see what web site they are visiting. The AMP cache breaks that experience. By serving the page from Google’s cache they may be confused by the ‘’ URL they see in the address bar.

Last November we at Cloudflare announced a technical solution to these problems that would allow AMP pages to be served from a cache while retaining the original page URL and all its benefits. The in-depth technical blog post by Gabbi Fisher and Avery Harnish gives the full details. The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from.

In cooperation with a browser that understands Web Packaging, this means that a page can be stored in an AMP cache and served quickly from it while showing the original site URL in the browser’s navigation bar. A major win all round!

We’re calling this “AMP Real URL” and it’s free to all Cloudflare customers.

How It Works

Google’s AMP Crawler downloads the content of your website and stores it in the AMP Cache many times a day. If your site has AMP Real URL enabled Cloudflare will digitally sign the content we provide to that crawler, cryptographically proving it was generated by you. That signature is all a modern browser (currently just Chrome on Android) needs to show the correct URL in the address bar when a visitor arrives at your AMP content from Google’s search results.

More importantly, your site is still being served from Google’s AMP cache just as before; all of this comes without any cost to your SEO or web performance.

Want to Learn More?

We will be hosting a webinar on Wednesday, June 19th at 10:00 am PDT “Building AMP Experiences that Drive Results” that will feature a broader understanding of AMP architecture and how AMP Real URL leverages Cloudflare’s serverless platforms to deliver signed exchanges. U.S. Xpress will also share insights and results that they’ve experienced having deployed Cloudflare AMP Real URL for their AMP content.

Register today!

Save the Date – AMP Contributor Summit 2019

Developer Experience, Governance

This year’s AMP Contributor Summit will be held October 8-10, 2019 in New York City, and we need your help to help make it happen!

The AMP Contributor Summit is a technical summit for AMP’s open source contributors.  At the first AMP Contributor Summit last year more than 80 members of the community got together to meet face-to-face, talk about the latest developments in AMP and discuss where AMP should head into the future.  At the end of the summit 100% of those who responded to a post-summit survey said they’d recommend the summit to members of the community.

Starting this year the AMP Contributor Summit will be organized by the community with guidance from the Outreach Working Group.  We’re looking for volunteers to help with all of the aspects of planning a successful summit–everything from setting a theme to vetting talks to dealing with schedule logistics.

If you’re excited about bringing the AMP community together and would like to get involved in planning the summit, please let us know by Tuesday, June 11.  We’re planning on having an organizational kickoff meeting on June 12 and it would be great to have you there!

If you have any questions, reach out to mrjoro on Slack or GitHub.

For everyone in the community, please save the dates of October 8-10, 2019, and keep an eye out for details on applying to attend the summit soon!

Posted by Joey Rozier, member of AMP’s Outreach Working Group and Engineering Manager at Google

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