Web Performance Calendar

The speed geek's favorite time of year
2015 Edition

Why AMP is fast

by MalteUbl
ABOUT THE AUTHOR

Malte Ubl (@cramforce, +MalteUbl) is the tech lead of the AMP Project. He previously spent 5 years at Google making JavaScript based apps go fast and in his free time, he is one of the co-organizers of JSConf EU.

The AMP Project aims to bring instant rendering to web content. This is an unsorted list of optimizations that apply to all AMP based documents, which in aggregate makes them load fast. Every web page can have these optimizations, but AMP pages cannot not have them.

While this article is about optimizations in AMP, it might also be useful as a kind of todo list for optimizing a non-AMP website. If we are missing any optimization that might be beneficial to AMP, please leave a comment or send us a pull request.

Lazy loading

Resources are lazy loaded when it becomes likely that they’ll be seen by the user or when the document is otherwise idle.

Extensive use of preconnect

The new preconnect API is used heavily to ensure HTTP requests are as fast as possible when they are made. This helps makes lazy loaded requests faster when they are eventually made.

Prefetching of lazy loaded resources

Resources are loaded as late as possible, but prefetched as early as possible. That way things load very fast but CPU is only used when resources are actually shown to users.

All async JavaScript

AMP files are only valid if all JavaScript files are loaded asynchronously.

Inline style sheets

Only inline style sheets are allowed in AMP. This removes 1 or often more HTTP requests from the critical rendering path compared to most web pages.

Zero HTTP requests block font downloads.

Because all JS in AMP has the async attribute and only inline style sheets are allowed, no HTTP requests block the browser from downloading fonts.

Instant loading through prerendering

AMP is optimized for making it relatively “cheap” and reliable to prerender a resource. This means that it is rendered before the user explicitly states that they’d like to navigate to a page. With this a page might already be available by the time the user actually selects it, leading to instant loading.

While prerendering can be applied to all web content, that may (and does in practice) use up a lot of bandwidth and CPU. AMP is optimized to reduce both of these factors:

Prerendering only downloads resources above the fold

When AMP documents get prerendered for instant loading, only resources above the fold are actually downloaded. Details.

Prerendering does not render things that might be expensive in terms of CPU

When AMP documents get prerendered for instant loading, resources that might use a lot of CPU (like third party iframes) do not get downloaded. Details.

Intelligent resource prioritization

When AMP downloads resources it optimizes downloads so that those resources that are currently most important for the user are downloaded first.

Uncoupling of document layout from resource downloads

External resources such as images, ads or iframes need to state their size in the HTML. That means they don’t have to be downloaded first to layout the document.

Maximum size for style sheet

The inline style sheet has a maximum size. While this size is big enough for very sophisticated pages, it still requires the page author to practice good CSS hygiene.

FastDOM-style DOM change batching

We batch all DOM measure and mutate operations to minimize style recalculations in the browsers.

In practice this means that in each “animation frame” we first do all the DOM read operations, and then when those are done, do all the write operations. The result is a reduction to 1 style recalculation per frame.

Optimized for low count of style recalculations and layout

Independent of the above, AMP is optimized to avoid expensive style recalculations and layouts in the browser.

Mitigations for third party JS worst-practices such as document.write

In particular if third party JS uses the super-bad-for-performance document.write API, it does not block rendering the main page.

Runtime cost of analytics instrumentation is independent of number of used analytics providers

The way analytics are being implemented in AMP, pages that have more than one analytics provider do not get bloated with additional JavaScript and do not use significant extra CPU.

Extensions don’t block page layout

AMP supports extensions for things like lightboxes, instagram embeds, tweets, etc. While these require additional HTTP requests, those requests do not block page layout and rendering.

CDN delivery available to all AMP documents

AMP offers a proxy-based CDN for delivering all valid AMP documents, offering fast and reliable performance across all AMP content.

All resources and the document are loaded from the same origin through the same HTTP 2.0 tunnel

When using the proxy-based AMP CDN, the document, all JS files and all images are loaded from the same origin that is using HTTP 2.0 for maximum efficiency.

Animations can be GPU accelerated

The rules for animation related CSS in AMP ensure that animations can be GPU accelerated on modern devices, so they are smooth and buttery.

This article is also cross-published to Malte’s Medium blog