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 benifitial to AMP, please leave a comment or send us a pull request.
Resources are lazy loaded when it becomes likely that they’ll be seen by the user or when the document is otherwise idle.
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.
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.
AMP files are only valid if all JavaScript files are loaded asynchronously.
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.
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.
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:
When AMP documents get prerendered for instant loading, only resources above the fold are actually downloaded. Details.
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.
When AMP downloads resources it optimizes downloads so that those resources that are currently most important for the user are downloaded first.
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.
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.
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.
Independent of the above, AMP is optimized to avoid expensive style recalculations and layouts in the browser.
In particular if third party JS uses the super-bad-for-performance “document.write” API, it does not block rendering the main page.
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.
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.
AMP offers a proxy-based CDN for delivering all valid AMP documents, offering fast and reliable performance across all AMP content.
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.
The rules for animation related CSS in AMP ensure that animations can be GPU accelerated on modern devices, so they are smooth and buttery.