AMP

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 cdn.ampproject.org. This will have two advantages: 

  • Faster time-to-interactive: downloading the AMP framework no longer requires establishing a second HTTPS connection to cdn.ampproject.org.
  • 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

Developer Preview of better AMP URLs in Google Search

Cache

AMP users and publishers have told us that they prefer that the original domain names be used anywhere their AMP pages are displayed.


Earlier this year, we demonstrated a technology named Signed HTTP Exchanges that supports transforming cached AMP URLs on any AMP Cache. Google Chrome has since started an origin trial for Signed Exchanges in Chrome 71. Today Google Search is opening up a developer preview of this technology that any publisher can try out for themselves.

Signed Exchanges, used by an AMP Cache, have benefits for users and publishers, beyond the visual experience of the URL bar. Signed Exchanges also:

  • Provide a guarantee, using cryptographic signatures, that the content is exactly what the publisher intended to show the user.
  • Allow the browser to treat a document as belonging to the publisher’s Origin. This allows a publisher to use first party cookies to customize content, execute service workers, and measure analytics.

Signed Exchanges are part of a wider web proposal named Web Packaging. The Web Packaging specifications, first proposed in 2015 as a W3C draft are evolving over time with feedback from members of standards bodies, other browser vendors, security experts, and publishers and web developers.

Steps to try a Google Search demonstration

  1. Signed Exchanges are currently only enabled in Chrome version 71 or greater. At the time of writing, this requires installing from the Chrome Beta channel but it will soon be released to all Chrome channels.
  2. If you are not using a mobile device such as a smartphone or a tablet, enable mobile emulation on your browser. AMP pages are only displayed to mobile devices. Next, visit https://g.co/webpackagedemo.
  3. This will display a search box. From there, enter a query such as [learn amp by example] and click on “Learn AMP by Example” for the ampbyexample.com home page. There are only a small number of publishers that have implemented this feature so far, so you may want to try this specific query. If you’ve completed these steps correctly, you will see “https://ampbyexample.com” displayed in the browser’s URL bar.

That’s it! The AMP Cache has preloaded the AMP document and Chrome has cryptographically verified that the AMP document was never modified from what the publisher intended, thus enabling the publisher’s URL to be the one that populates the browser address bar.

Under the hood

Prefetching

The moment a Google Search returns an AMP result, the Search results page instructs the browser to fetch the AMP document, “prefetching” it by the device in the background.

When a user clicks on that result, the AMP document can be displayed instantly. This works in part because the document clicked was already fetched and partially loaded.

Heavy resources like images and videos haven’t all been fetched in advance, but the AMP JavaScript libraries make sure to reserve space on the document for those and optimizes the order of loading them. This saves bandwidth if the user doesn’t end up clicking. It also protects the user’s privacy.

An important privacy principle is that until the user clicks on a document, third parties should not be able to determine that the user is interested in it. If preload caused a browser to make network requests to servers other than Google’s, then some of the intent of user queries would leak to sites the user never even clicked on.

To achieve this, neither the document nor any resources fetched before loading the document, can be fetched from third parties. Only once the user has signaled intent to load the document by tapping it do those resources get fetched. We call this mechanism “Privacy Preserving Prefetching” and it provides a buffer between the user and the publisher until the user has chosen which document to visit.

In order to preserve privacy while still prefetching documents, the referrer, Google Search in this case, must load the document from a Google server, the Google AMP Cache.

Signed Exchanges

We would like to achieve the Privacy Preserving Prefetching while simultaneously maintaining the URL and Origin model of AMP documents. We are achieving this using a new collection of browser technologies being drafted under standards bodies such as the W3C and IETF, called “Signed Exchanges”.

A Signed Exchange is an HTTP Request / Response pair, cryptographically signed using a publisher’s own Certificate Private Key. In other words, Signed Exchanges provide digital proof to a browser that the document delivered by an AMP Cache has not been modified from what the publisher intended.

When a browser sees a Signed Exchange and can validate the signature, the browser can display the publisher’s URL, regardless of where the file was delivered from.

AMP Packager

To help publishers build Signed Exchanges, the AMP team has built a tool that can be run by publishers to package and serve Signed Exchanges. The tool is called the AMP Packager.

The AMP Packager runs on publisher’s own infrastructure as a web server backend. It acts like a proxy, accepting an HTTP request for an AMP Web Package, forwarding that request to the publisher’s own backend, and then transforming it into a Signed Exchange.

In addition to packaging the document, the AMP Packager also applies transformations to the document that optimize the page for serving on an AMP Cache. These transformations modify the document itself, without changing the way it looks to users. However, publishers should be able to inspect the code that makes these transformations, so the AMP Packager code, including the transformations applied, is open source.

Developer Preview

Developers who want to opt-in to this developer preview should be first aware that the specification is still changing, and this is an implementation of a snapshot of it.

Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.

Option A: Run the AMP Packager tool

The AMP Project has provided the AMP Packager, an open source tool, with detailed instructions on how to run it on your own infrastructure.

During these steps, you will need to generate a new certificate with the CanSignHttpExchanges extension from your Certificate Authority. At the time of writing, the only Certificate Authority that has built a Signed Exchange certificate request flow is DigiCert, with detailed instructions that can be found at Digicert CanSignHTTPExchanges.

Option B: Use a Signed Exchange–Enabled CDN

If you use a CDN provider, ask them if they can provide AMP Signed Exchanges.

At the time of writing, Cloudflare has announced an experimental Cloudflare Worker application implementation of Signed Exchanges as a service to its customers. See this Cloudflare blog post about Web Packaging for more information on how to enable Signed Exchanges on Cloudflare. Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.

We’d love to hear from you

We would love to hear your feedback on Signed Exchanges in AMP. You can join the spec discussion, report a chrome bug, report an AMP Packager bug, or general AMP feedback. Your feedback will greatly help us shape the future of AMP and the web.

Posted by Greg Grothaus, Software Engineer, AMP at Google