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:
- 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.
- 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