This is a really hard problem to solve, so we decided to reduce scope. The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content as it lends itself to more radical optimization approaches that are easier to apply across the board.
We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance? That experiment has culminated in a promising proof of concept we call Accelerated Mobile Pages (AMP). AMP HTML is built on existing web technologies, and the documents written in it render in all modern web browsers and web views. In fact, this page is, itself, an AMP HTML document.
The page you are currently reading is an AMP HTML document.
We think AMP HTML is promising, but we know it's not complete. We are sharing our proof-of-concept on GitHub to start a conversation about how to make static content on the web fast. We want to collaborate with the entire web community to develop this promising idea into something more real, sharing our techniques, ideas, and code.
AMP HTML loves CSS!
So, AMP HTML comes with strong limitations on JS. What about CSS? AMP HTML loves CSS! We do add some best practice enforcement, but we do want AMP HTML documents to look like their authors intended them to, and so allowing extensive styling is core to the platform.
noscript version that makes this easy. More advanced analytics are currently not supported. Our vision is to deploy a single, unified, auditable, high performance, open source analytics library with AMP HTML that can report to various existing analytics provider backends, so it is possible to use the existing ecosystem without overloading a page with analytics software.
document.write. We also prioritize ads lower during loading than other content and optimize load timing to avoid jank. Ads in AMP files can still be heavyweight, so there is still a lot of work to do for us.
AMP HTML is pretty fast.
So, how fast is AMP HTML? Pretty fast. In a sample of pages our early partners created we are seeing performance improvements measured through Speed Index between 15% and 85%. This was measured with a simulated 3G connection and a simulated Nexus 5 device. The best part is you don't need to be a performance expert to get this; best practices are baked right in. And as we optimize AMP HTML in the future, all pages benefit.
But how do we get from good to, let’s say, instant? We’ll cheat :) AMP documents are from the ground up designed to be efficiently pre-renderable. Browsers have long supported pre-rendering through the
<link rel=prerender> tag, but they need to be conservative about this mechanism because prerendering can be expensive. With AMP HTML we added the ability to tell a document: render yourself, but only as far as what is visible above the fold and only elements which are not CPU intensive to minimize the cost of pre-rendering. With this mechanism in place, referrers of AMP document can initiate rendering of docs before the user acts much more aggressively, so that in many cases the document will be done rendering by the time the user clicks.
Our goal with AMP HTML is reliable performance, so we designed it to be easily cacheable by content delivery networks (CDNs). Google is offering a service that delivers AMP HTML documents given their URL through its CDN. Others can use this service or make their own or serve AMP HTML pages from a plain-old-web-server.
Resources must declare their sizing up-front
This brings us to the final topic that makes AMP HTML unique: all resource loading is controlled by the AMP library and, more importantly, resources must declare their sizing up-front. Document authors have to state resource sizes explicitly. This doesn’t mean that resources can’t be responsive – they can be, but their aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action. An ad at the top of the page can’t suddenly say: “I want to be 200 pixels high instead of 50.” This dramatically reduces jank and prevents users from losing their place in the document. All custom elements are subject to this restriction. Placement on the screen can be reserved while their implementations download asynchronously. This gets us lazy loading with zero visual jank.
To summarize: AMP HTML is a specialized subset of HTML with custom elements that provides reliable performance and instant loading of static content. Nothing about the project is set in stone. We are sharing an early version of the AMP HTML spec as well as a prototype implementation on GitHub and we are looking forward to collaborating with the community on all aspects of the project. We expect there are still low (or not so low) hanging fruit for performance optimization that we missed, so if you are an expert in web performance or just want to dig in we’d love your help. Also, if you happen to know a lot about publishing documents on the internet we’d love your input: Maybe some of our restrictions are a bit too drastic for the things you work on. We’d love to hear about those cases, so we can thoughtfully extend the capabilities of AMP HTML while keeping pages lean and fast.
See you over on GitHub!