Powerful impact: Why we AMPized the Australian pop culture site – GOAT


Editor’s Note: The following post was written by Leo Postovoit, Strategist at XWP.

NOVA Entertainment is one of Australia’s most recognized media brands with a history of radio, media, and local content stretching back 19 years; and GOAT is NOVA’s pop culture, news and entertainment platform built for a mobile-first audience. 

GOAT is the first of NOVA’s sites to benefit from development of a progressive-focused WordPress build. As GOAT’s editorial goals include bringing their content to people in a format they find accessible, convenient, and speedy—performance and usability are top priorities. This study reviews how AMP and PWA brought impact to Goat’s recent technical relaunch.


The GOAT website experienced issues with performance and usability. To improve user experience and  compatibility with many devices, priority one was to improve the performance of the site. The site’s delays in rendering content and assets were barriers to users and their onsite and sharing behavior. This is not surprising, given that research studies consistently demonstrate how critical performance is for the level of engagement a site receives.

At a tech conference in Tokyo this year, Googler Jeany Halliman opened her speech about a study that Google conducted on site visitors of Media sites about “the one thing they disliked the most when browsing a site”.

“Coming from the ad business, I always thought it would be ads (visitors disliked). But the majority of users said it was a slow website.” – Jeany Halliman

This response correlates clearly with the well observed impact on bounce rates that page speed has, yet its precedence over on-page ads is a surprise to many due to recent attention and “backlash” many Media sites have received about overbearing Ad strategies.


NOVA reached out to XWP, an ecosystem leader in WordPress engineering, and maintainer of the official AMP Plugin for WordPress in partnership with Google. Well known for producing elegant and complex solutions for major publishers such as Rolling Stone, News Corp Australia, and Rogers, and technology partners — such as Cloudinary, Google, BigCommerce, and Automattic, XWP work focuses on building a better web.

Since performance, scalability, and usability were key goals outlined by stakeholders at NOVA, it was clear to XWP that a progressive AMP approach was the way to go.

While the primary objective of the migration to an AMP-first strategy was clear: to create a fast experience that users love to return to and share, it was important to also ensure scale and stability through best development practices including CI/CD, automated testing and high-availability hosting. Combined with high code quality and modern WordPress practices in mind, the GOAT site was made not only to be quick, but also built to last.


With XWP’s experience with AMP and other ways to impact performance, they considered various implementations to achieve NOVA’s goals for the GOAT website. An AMP-first strategy was the best fit because it allows for streamlined development around a single code base.

Going one step further, GOAT seemed to be a great use case for the PWA feature plugin (another collaboration between XWP and Google). This added the ability to provide capabilities such as offline mode, notifications and the like, powered by service workers. And the solution defined leverages the amp-install-serviceworker component, which makes it easier than ever before to combine the benefits of AMP and PWA.

While the PWA features included today are limited in scope, the long-term goals are to add installability on desktop and mobile devices, richer offline mode and pre-fetched pages, native push notifications and the like—just like other powerful PWAs across the web.

Incorporating Ads 

When ad loading is not configured properly it contributes towards poor page performance, especially on media-rich sites like GOAT. Working with AMP means the approach XWP took to implementing GOAT’s ad stack had to adhere to AMP standards.  Whilst some concessions had to be made to accommodate ad providers which were not fully AMP compatible the overall effect was a highly performant ad-reliant media site. The best of both worlds: a good user experience that isn’t degraded through sub-optimally loaded ads.

The Results 

As discussed, Goat is the first of Nova’s sites to go live with a unified editorial workflow and performance-focused theme build—as a PWA site, with all templates built as Native AMP. The performance results are noticeable:  

  • The unification of the editorial experience across multiple properties
  • Google Pagespeed Insights score went up from 7 (yes 7) to 77 on mobile
  • WebPageTest 3G test: before / after . Key things: start render time decreased by 1.5s. The time to interactive went down from 43s to just 10
  • Lighthouse test: before / after . First contentful paint went down from 5.8s down to 2.5s (a 3.3s reduction). The performance score went up from 7 to 65. First CPU idle time went down from 16.2s to 5.9s
  • GTmetrix: before / after . The PageSpeed Score went up from a D (63%) up to B (82%)

Start Utilizing AMP

Based on results as the ones obtained by Goat’s site AMP-first strategy, we recommend learning more about how AMP can be the solution to your current business challenges.

  • To find out more about AMP, visit the project homepage at  
  • To evaluate your site’s compatibility and see if you can also gain the performance and user experience benefits of AMP, check out, XWP’s service to bring the benefits of AMP to your WordPress sites.

Written by Leo Postovoit, Strategist at XWP

AMP Advisory Committee midterm election results


In early August, we announced a midterm election for the AMP Advisory Committee (AC) with the goal of increasing the diversity of the AC’s membership.

Right after we announced the election, Dane Knecht of Cloudflare resigned from his position on the AC, thus freeing an extra seat, but also reducing the presence of CDNs in the committee to zero (Charles Vazac having left Akamai earlier this year). With Web Packaging being such a hot topic, not having a CDN representative onboard was—understandably—a real issue for many on the committee.

We initially wanted to add about four new members to the committee, which we increased to five following Dane’s departure. We gave ourselves a bit of leeway however, in case we couldn’t find the right people or on the contrary where overwhelmed with great candidates. Fortunately, the latter is what happened. And despite opening up two extra seats (including Dane’s), we had to reject some amazing candidates. Hopefully, they’ll apply again when we run our regular elections at the end of the year. We’ll make sure to remind them.

So, without further ado, we’d like to introduce you to the six new members of the AMP Advisory committee, in alphabetical order:

  • Ali Ghassemi is passionate about the Web and started his career in 2005 finding workarounds for IE6 quirks. Ali currently works at LinkedIn Inc. on’s Web infrastructure. He was previously a tech lead in AMP working on UI components.
  • Jervay Singh is a performance marketing solutions expert for a large financial services company in South Africa. He wishes to bring an emerging economies perspective to the committee, along with his passion for driving AMP takeup within the South African and African market.
  • Maggie Wettergreen is a web developer and designer focused on building quality user experiences. They have developed AMP pages in multiple environments, notably WompMobile’s third-party AMP system. Maggie wants to ensure that AMP is moving consistently toward being a staple development framework.
  • Melanie Sumner is a software engineer who is passionate about improving “accessibility by default” on the web. Melanie is concerned about AMP’s accessibility and intends to contribute her expertise as an engineer and advocate for an accessible, open web.
  • Melissa DePuydt is a frontend engineer currently working as an engineering manager. She previously led solution architecture for clients at Arc Publishing at The Washington Post, where she became interested in build processes and practices that make AMP integration more sustainable and push news websites toward better performance.
  • Ted Shuter is a product leader at Akamai, focused on making the web a faster, better place to play and work. Ted loves the concept of improving performance, but wants to make sure it is fair and balanced for all users. In particular, Ted brings the perspective of business users and the impact to Content Delivery Networks.

Hopefully, you’ll get to meet some of them at the AMP Contributor Summit in New York, which is just around the corner.

We’re very excited to welcome these new members to the AC and look forward to working together.

Posted by Tobie Langel, AMP Advisory Committee facilitator.

How Developers are Creating WordPress AMP Experiences Content Creators LOVE to Use


Editor’s Note: The following post was written by David Vogelpohl, VP of Web Strategy at WP Engine. WP Engine is a digital experience platform for WordPress.

In the web development world we often use tools for automation, read books on project efficiency, and deploy an army of techniques to deliver innovation at a faster and faster rate. While we often ask ourselves, “How can we be better at fishing?” many of us rarely ask ourselves “How can we enable our marketers and content creators with the tools they need to fish for themselves?”.

This article tells the story about how and why WP Engine invested in leveraging AMP to help developers create performant, beautifully designed, and feature-rich experiences that content creators LOVE to use.

Why does WP Engine care about development & design efficiency?

In mid 2018, WP Engine purchased Genesis, a theme framework for WordPress and the Atomic Blocks plugin as part of our strategy to deliver intuitive and powerful design and development solutions. Atomic Blocks is a WordPress plugin that includes a library of pre-designed and configurable website components called “blocks” and arrangements of blocks called “layouts” that make it easy for site creators to design and deploy new experiences.

Atomic Blocks users can now leverage the power of componentized page building while creating 100% AMP validated experiences.

This is often achieved with Genesis and Atomic Blocks by leveraging the new block based editor in WordPress which was code named “Gutenberg” during its release to WordPress #core in late 2018.

Users can style WordPress blocks in any fashion (Genesis helps with this); providing configurable design controls to fit branding, pre-loading blocks with content, and integrating blocks with other extensible systems or software.

Here is an example of the block editor in use with Atomic Blocks.

Here is an example of a StudioPress theme which uses this modular-block approach, is highly configurable by content creators, was updated to use AMP, and has an incredible score of 95 on Google’s Page Speed Insights (up from a score of 54 pre-AMP). Genesis users can also make their own custom themes. Here is an example of an AMP site using a custom built Genesis theme. Regardless of the choice of pre-designed or custom themes, thanks to AMP our customers can build incredibly fast sites faster than ever!

Why did WP Engine decide to add AMP support to Genesis & Atomic Blocks?

Considering the desire for certain brands to adopt AMP and the fact that our agency and developer customers felt they were without product support from us or even other products in the WordPress ecosystem, we felt it was imperative to support them when building with AMP.

Of course, with our stated mission of providing developers with tools that make it easy to create experiences content creators love to use, we had to go about this in a way that not only made it frictionless for the developers to create those experiences, but also to do so in a way that allows content creators to not have to think much about AMP compatibility when creating the landing or web pages they need to create.

The content creators had to LOVE creating AMP compatible experiences for their brand.

Adding new features or support for certain standards such as AMP is a tall ask for design and development tools as popular as Genesis or Atomic Blocks. There are considerations for the >600K sites that use those products and an army of developers around the world who rely on those products as part of their daily workflows.

As with many of you, we take great care every time we consider adding something new to our products. When it came to AMP support, we started by getting a pulse from customers on how often they use AMP, what they like about it, and what they don’t.

The feedback we received was somewhat typical of what you’d expect from a broad audience of web developers relative to AMP. Most had actually never built a site with AMP and claimed that their downline customers rarely asked for AMP sites. That being said, many acknowledged that they did have certain key customers (particularly in publishing) that would request AMP sites and that those asks were often rooted in a desire for performance and improved search/social visibility within various platforms.

We then asked, “For customers pursuing an AMP strategy, what tools or techniques do you use to satisfy those demands?” The answer was a bit shocking. The overwhelming response was “We don’t have any!”

How we approached AMP support within Genesis & Atomic Blocks

Google and other contributors released an AMP plugin for WordPress in 2019. This plugin enables many of the key capabilities of AMP for WordPress sites and is optimized for the WordPress core themes. Core themes are themes which are included with WordPress itself; however, most WordPress sites are powered by custom themes created by developers or premium themes created by companies like WP Engine.

Custom themes and premium themes (created with Genesis or otherwise) require the developers of those themes to optimize their code to help ensure AMP compatibility even when using the AMP plugin for WordPress. For example, some of WP Engine’s premium themes included elements which weren’t AMP compatible, so any users of those themes would experience failures in AMP validation.

Additionally, plugins which power front end experiences such as our Atomic Blocks plugin also must make sure their code is optimized to ensure 100% AMP validation.

The AMP plugin for WordPress does take care of a ton of the work in making a WordPress site support AMP; however, certain aspects of your site may require additional work as illustrated above.

Because of these requirements, we embarked on a mission to add capabilities to Genesis for developers to create custom themes with 100% AMP validation, update key premium themes for AMP compatibility, and to replace elements of Atomic Blocks which failed AMP validation.

Building custom AMP themes with Genesis

In our Genesis 3.0 release we added capabilities that allow developers to more easily create 100% AMP validated custom themes.

Creating a 100% AMP validated theme with Genesis starts with installing the AMP plugin for WordPress. The contributor team on the AMP plugin did an outstanding job, so Genesis theme developers get a lot of free wins just by running this plugin.

Here’s a screenshot of what WordPress users see when using the AMP plugin.

Two of the key benefits in the Genesis world related to the AMP plugin is the fact that it automatically converts markup to AMP HTML and handles CSS tree shaking to help theme developers stay within the 50KB CSS limit.

That being said, Genesis itself and certainly many themes made with Genesis have or had Javascript dependencies which of course would cause the site or certain pages to fail validation. In relation to Genesis itself (vs. “child themes” built with Genesis), some of the key areas of JavaScript dependency were the Genesis menu style system (specifically with “Superfish”), JavaScript related to threaded comments, and scripts related to skip links.

In Genesis 3.0 we replaced these dependencies or made them optional / disabled when running with AMP.

Some of the benefit to Genesis developers is that child themes no longer need to include their own responsive-menus.js script or do any of the work to enqueue it. Genesis now includes this script and handles all the work of enqueueing it, if you utilize the new responsive menus API.

The end result is that it’s easier to build 100% AMP validated themes with the Genesis framework than ever before. Using these capabilities we have been able to easily update two of our premium child themes to be AMP compatible and countless other custom child themes in the Genesis ecosystem have also been updated or created with AMP compatibility.

Since the launch of Genesis 3.0, the community response has been largely positive with many examples of developers not only adopting AMP as part of the sites they build, but also sharing their knowledge and experiences with others as seen here in this great post titled “Building a Native AMP WordPress Site”.

AMPing up the WordPress block editor with Atomic Blocks

Just as custom themes require developers to optimize their code for AMP, plugins which control front end experiences must do the same. In our case, the Atomic Blocks plugin provides a rich experience for site creators to use website components called “blocks” to create new experiences regardless of the theme they use.

Making Atomic Blocks AMP compatible was actually a somewhat easy undertaking as only a few elements of those blocks were failing AMP validation. To me, this is a great example of how many design and development tools are largely AMP compatible as is without the need for a complete refactor.

In the case of Atomic Blocks, we were able to refactor the parts of the blocks and layouts the plugin enables to be AMP compatible. The work was so light, we were able to accomplish this in just one sprint!

In the example below, you can see how easy it is for content creators to create beautiful, performant, and functional AMP experiences without even realizing that those experiences are 100% AMP validated.

These are the types of frictionless experiences that deliver great value to marketing teams and help keep roadmap-zapping, soul-crushing landing page tickets out of dev teams’ backlogs. In this way, brands can leverage the power of AMP while creating new experiences in hours vs. days or weeks.

The future of AMP for WP Engine’s design and development products

For the Genesis theme framework, our engineering teams are keeping up with the evolution of AMP to ensure that our customers are armed with the latest capabilities within the themes they build with Genesis. We are also looking at expanding AMP support across our inventory of premium Genesis themes so customers have more choices when leveraging premium themes and AMP.

For the Atomic Blocks plugin (which is also used in our premium AMP themes), we are continuing a 100% AMP validation approach so users of Atomic Blocks can enjoy the full feature set of Atomic Blocks in an AMP context.

While we realize that some customers or the downline brands they serve may not choose to deploy an AMP focused strategy, it’s important to us that when they do, we arm them with tools that allow developer teams to be able to create beautiful, performant, and functional experiences that content creators LOVE to use.

Written by David Vogelpohl, VP of Web Strategy at WP Engine

Analytics for your AMP Stories


AMP stories are a new way of telling stories on the open web. The stories are hosted on your domain, and the format allows you to add assets best suited for the job. Since the 2017 launch, we’ve seen many, many, many examples of engaging and informative stories published to the web.

Analytics capabilities of AMP stories

AMP stories use amp-analytics, the same robust measurement tool behind billions of AMP pages. Publishers can instrument their stories using simple JSON configuration, and the component does the setup, collection and reporting of metrics. If you’re using one of the 75+ analytics vendors that are already integrated with AMP, you can start collecting insights with very minimal setup.

Understanding user-behavior

A typical user-journey for a website is very different from stories. On a website a user might read the headline, scroll to the bottom of the page, interact with a form before clicking on a link to the next page. Stories occupy the full viewport and users do not scroll but tap to move forward.

Many in the web analytics community would consider each new page in the story as a new pageview because the content from screen to screen is substantially different. However, as we just covered, the page is just a single element in a full story — and a user usually needs to see many pages to get a full sense of the story. Thus, the question of how we count something as simple as the pageview has enormous implications for our analytics approach. As you see from above, treating every new story page as a pageview could be perceived as inflated metrics.

A better default configuration

AMP Analytics makes it easy to implement the above using any analytics vendor. For instance, with Google Analytics’ Global Site Tag it looks like so – 

<amp-analytics type="gtag" data-credentials="include">
 <script type="application/json">
     "vars": {
       "gtag_id": "YOUR_GOOGLE_ANALYTICS_ID",
       "config": {
           "groups": "default"
     "triggers": {
       "storyProgress": {
         "on": "story-page-visible",
         "vars": {
           "event_name": "custom",
           "event_action": "story_progress",
           "event_category": "${title}",
           "event_label": "${storyPageId}",
           "send_to": ["YOUR_GOOGLE_ANALYTICS_ID"]
       "storyEnd": {
         "on": "story-last-page-visible",
         "vars": {
           "event_name": "custom",
           "event_action": "story_complete",
           "event_category": "${title}",
           "send_to": ["YOUR_GOOGLE_ANALYTICS_ID"]

This default config should give you a complete working configuration for your AMP stories. 

If you’re interested in going beyond what the default config can give you, read on to find more advanced use cases with Google Analytics.

Advanced setups

Insight #1: What’s my most visited page/slide for a given story?

Create a dashboard in Google Analytics’ web interface by going to Customization > Dashboard

Assuming you assign unique names to your AMP stories in “event_category”: “Title of my story”, we can see what pages were visited mostly by creating a bar graph in your custom dashboard picking dimensions “event_category”, “event_label” and metrics “Hits”.

Make sure to add a filter so that you are filtering “Event Action” to exactly match “story_progress”:

Insight #2 What’s my most visited story across the site?

Create a dashboard in Google Analytics’ web interface by going to Customization > Dashboard.

Assuming you assign unique names to your AMP stories inside your <title></title> tag pair, , we can see most commonly visited pages by creating a bar graph in your custom dashboard picking a grouped by dimension “Page Title”, and choosing the metrics “Pageviews”.

Get started quickly by using this premade Google Analytics template.

Insight #3 : For a given story, how far into the story users typically go

Since the story progresses from slide 1 to slide N,  it is natural that slide 1 is seen by almost everyone, slide 2 a little less and the number progressively goes down. If there are any problematic slides, you will see a dramatic drop in slide viewership from the previous one. The following dashboard will help you visually capture any problematic pages.

You can use the dashboard that you created before ( Insight 1 : Most visited pages by story) to visually capture this

Insight #4: What’s the average number of pages my users see per story?

It is also possible to track events on an average. For instance, story progress can be used to track average story depth. 

  1. Navigate to Behavior > Events > Top Events. 
  2. With “Event Category” as the primary dimension, click on the pie chart icon. 
  3. Add a Secondary Dimension as “Event Action”.
  4. Click on Advanced. Select “Event Action” and select “Story Progress” in the filter and apply.
  5. Select “Avg. Value” from the drop down. 

Insight #5: How long on average do users spend on my stories

Average session duration is the total duration of all sessions (in seconds) / number of sessions. 

Create a new dashboard or add a widget to an existing one with the following setup

Insight #6: Measure how many times ads were shown on my story

AMP stories can insert ads on your stories via the <amp-story-auto-ads> component. The following setup helps you visualize the number of times ads were shown on the story.

Create a new dashboard or add a widget to an existing one with the following setup:


In this post, we shared various ways of using AMP Analytics with Google Analytics, to measure unique ways in which users interact with AMP stories. 

If you have feedback or questions on your AMP story analytics setup, please open a Github issue.

Happy measuring!

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

Making Your Wait a Little More Great: New Loading Indicators in AMP


This post is from the AMP Design Team. We’re product designers and researchers responsible for making sure AMP’s components and overall experience are usable, accessible, and elegant. You can find us hanging out with the UI and Accessibility Working Group on GitHub or in the Contributor Slack.

One of the biggest ways that AMP improves web users’ daily experience is by helping developers make sites that are fast. A unique advantage of AMP is that it’s always improving behind the scenes – we can roll out speed improvements to sites that use AMP without developers needing to do anything.

Performance best practices have always been baked into every corner of AMP, but actual speed is only half the story. While engineers continue to sweat the technical details, on the design team we set out to improve perceived speed. Waiting will always be a part of life – there are some parts of AMP pages our engineers can’t make faster because they come from a service we don’t control (like a Facebook post or YouTube video) or just because they’re large. But there’s plenty of evidence that the environment you’re in affects how you feel about having to wait.

If you’ve used more than a few AMP pages, you may be familiar with the loading indicator we’ve used since AMP launched in 2015:

Today we’re beginning to roll out a new one:

Let’s look at how we got here. We started with three goals:

  1. Make loading feel faster.
  2. Let readers know what’s coming. Since 2016, we’ve used a different loading indicator for ads on AMP pages so people could immediately tell them apart from the main content. We wanted to extend that to more types of content – videos, tweets, Facebook posts, and more – so you don’t have to wait for a video to load only to realize you’re not in a situation where you can watch one, for example.
  3. Modernize the design. We can’t put numbers on this, but many folks on the AMP team felt our loaders could be more visually elegant.

We also needed to keep the design elegant, but neutral. UI that ships with AMP needs to fit in well with the design of any AMP page – that means no dramatic colors or noticeable styling.

We did some prototyping and asked a panel of 2500 web users to look at one of ten different loading indicator designs that “loaded” content after a set amount of time and predict how long it took. The accuracy of the predictions wasn’t important—humans aren’t good at estimating very short durations—but the trends were. Participants estimated that they were waiting nearly a second less with some of our new designs compared to traditional options like the existing AMP loading indicator or a basic spinner. Based on this data and some observations we got excited about during the design process, we chose a design.

We landed on three principles:

  1. Sometimes no loader is better. Showing a loader before you’ve even noticed you’re waiting can be distracting and make the site seem slower.
  2. Keep it interesting. Having to wait isn’t helped by seeing the same repetitive spinner you’ve seen a million times.
  3. Keep it consistent. Having multiple things loading on one page, each with its own loader design and timing, is distracting and sloppy.

To satisfy the last principle, we made sure our design could be adapted to different sizes, content-type icons, and backgrounds. To satisfy the first two, our loader animated in several stages: first we would show nothing, then we’d show an intermediate animation, then finally we’d finish on a spinner that looped until the content was loaded. People wouldn’t see a loader at all if the content took less than a half second to load, and they wouldn’t see a repetitive spinner unless the content took a full 3.5 seconds.

Our design met all three of our goals: we had encouraging data on its perceived speed, we felt strongly that it was more elegant, and it did a good job letting readers know what was coming.

There were some additional details to figure out to maintain AMP’s flexibility for developers. We didn’t want the new design to conflict with AMP’s ability to show a placeholder image, message, or even a custom loading indicator before content has loaded. For content with a simple placeholder image, we still want to indicate to readers that something more is coming, so we’ll show a special version of the loading indicator that will stand out on any color image. For any placeholders more complex than that – messages or custom loading indicators, we won’t show the default loader at all to make sure our design doesn’t clash with yours.

The final proof will be in the live experiment we’ll be running in the upcoming weeks: launching our new loading indicators to a small percentage of AMP pages and keeping a close eye on site performance metrics as well as community feedback. Based on this feedback, our aim is to roll out our new loaders to all components on all AMP pages.

We hope you enjoy the new design and support us in making the user experience of the web better, one small detail at a time.

Posted by Andrew Watterson, Product Designer for the AMP Project at Google

amp-script: AMP JS


Earlier this year at AMP Conf, we introduced the developer preview of <amp-script>. Now we are announcing the general availability of <amp-script>. It’s an AMP component that runs your own JavaScript in a separate Worker thread. This lets you to add custom JavaScript to your AMP page while still retaining its lightning-fast speed!

<amp-script> lets you cover use cases that you couldn’t with existing AMP components. It also lets you share code across your AMP and non-AMP pages. You can even use a JavaScript framework. Here are some of the examples that the team working on <amp-script> has built:

Example of multi-page form with validation between sections

If the above examples interest you, do give <amp-script> a try. Do keep in mind that, in order to preserve AMP’s performance guarantee, there are some constraints:

  • Content jumping: To avoid unexpected content jumping, <amp-script> generally requires user gestures to change page content. 
  • Page load: Since <amp-script> doesn’t change page content without user interaction, it doesn’t modify content on page load either.
  • Script size: The script used in a single <amp-script> must be smaller than 150kB. Please note that you’re welcome to use your favorite JS framework, but it must fit within that 150K limit.
  • API support: Not all APIs are supported inside a Web Worker and WorkerDOM has a list of allowed APIs. In addition, some DOM methods and properties are not yet implemented. The full list is available publicly in WorkerDOM compatibility. Please file an issue if there is an API that you want to see added.

<amp-script> is compatible with frameworks you may already be using such as React, Preact, Angular, Vue.js, jQuery and D3.js.

This was one of the most important requests from developers using AMP. AMP Project is excited that we could help address this while still retaining AMP’s value proposition of speed. You can learn more about how <amp-script> works under the hood here and try out <amp-script> by following this guide. It’s a great way of unlocking a large number of use cases that weren’t possible before!

Please let us know if you have any issues or feature requests, when using <amp-script>.

Posted by Naina Raisinghani, Product Manager, AMP Project at Google

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 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 Advisory Committee midterm election


Update: the results are in!

In September 2018, Malte Ubl—then AMP’s tech lead—announced a new open governance model for AMP built around a series of working groups and two committees: the Technical Steering Committee (TSC), responsible for the direction of the AMP project and day to day operations, and the Advisory Committee (AC), which provides perspective and advice to the TSC.

An important goal of this governance change was to ensure that the voices of those who do not contribute code to AMP, but are nonetheless impacted by it, get heard. This responsibility is shared across all contributors but falls particularly on the shoulders of the AC, which has a duty to ensure its membership is as representative and diverse as possible.

Despite spanning nine(!) time zones, representing a wide variety of constituencies, and being fairly diverse, the AC’s membership is still predominantly US-based, white, and male. This is one of the main reasons why the AC has decided to expand its membership by about four members and is running a midterm election (terms are a year and are renewable).

All candidates are welcomed and encouraged to apply, but preference will be given to those who bring an underrepresented perspective to the AC and help broaden its horizon.

For a better understanding of what the AC’s work consists of, you may have a look at its GitHub repository and in particular its working mode document, the minutes of past meetings, its issue tracker, and its project board. The AC is fully distributed. It works asynchronously over email and GitHub issues (although its work isn’t technical), meets every other week over video conference, and roughly every six months face to face.

Financial support for travel expenses is provided to members for whom the position isn’t relevant to their day job, who are self-employed or unemployed, or who are working for structures for which such expenses wouldn’t be possible.

If you have questions, feel free to reach out to Tobie Langel, the AC’s facilitator.

Else, if you’re interested in joining the AC, please apply by filling in this form.

We will be collecting new applications until Friday, August 23 at 23:59 UTC. The AC will elect its new members through the consensus based process and will announce the result on Monday, September 2.

Posted by Levi Durfee, AMP Advisory Committee member, and Tobie Langel, AMP Advisory Committee facilitator.

AMP Roadshow: It’s Everywhere!


In June, we held an AMP Roadshow in Berlin in conjunction with JS Conf EU. We held another in Atlanta as an adjunct to, a new conference devoted to diversity and inclusion in tech.

This year, we’ll continue bringing the AMP Roadshow to new places and new people in several ways:

  1. Tech conferences. In August, we’ll be running an AMP Roadshow / learning event at BrazilJS, where we’ll also be giving two talks. We’ll have more AMP learning events at Brazil JS on the road.

  2. New locations around the world. We’ll hold AMP Roadshows in Sydney, Melbourne, Auckland, Tel Aviv, Istanbul, Dubai, Karachi, Warsaw, Kiev, Busan, Seoul, Hong Kong, and Dhaka (stay tuned for links to other locations on

  3. Do it yourself. Get in touch with us via the forms on our Roadshows page. Ask us to visit your city. Or sign up to run your very own AMP Roadshow! We’ll give you all the materials you need.

  4. AMP Study Jams. All around the world, Google Developer Groups will be running AMP learning events. There are about 1000 GDGs worldwide. Find one near you!

Finally, we’ve updated all the talks with information about all the exciting new things in the ever-expanding world of AMP, including the latest on Email, Stories, JavaScript in AMP, Analytics, the WordPress plugin, and so much more!

Check here for more information and to sign up. We can’t wait to meet you!

AMP Roadshow Shanghai

Posted by Ben Morss, Developer Advocate, Google