There’s a “technical” article explaining the ideas and concepts behind it and this is where I’ve pulled these quotes from. Now I want to be really clear up front, I’m ALL for improved performance. We need to build our websites in a mobile first, progressively enhanced way and anything that can help us build a faster and more universally accessible web is a great thing and I’m totally behind.
The comments I’m making below are genuine concerns and confusions so I’d love to hear from anyone with clarifications and I’m happy to update the post as we go.
Web performance is not unexplored territory for the tech community: books have been written about it, many talks have been given – there is even an entire conference series dedicated to the topic. However, users still frequently see poor web performance in the wild, particularly on mobile devices.
I agree that we have poor web performance in the wild, and mobile device access is certainly a problem… but I don’t think we should seek for a solution to solve just that problem alone. We need to be looking at a solution that fixes that at the core and therefore cascades outwards for any viewport or device accessing the content.
Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.
Again this isn’t an issue limited to accessing content over mobile, it extends across all devices and viewports.
Over the last several months, discussions between publishers and technology companies began in earnest about the need to improve the entire mobile content ecosystem for everyone – publishers, consumer platforms, creators, and users.
This sounds like they’re referring to the move Facebook proposed to include content via Facebook only, making the pages fast by stripping back all the poor implementation practices and focussing on the content itself. Apple have also looked at controlling this by introducing Apple News that will do the same (although it seems they’ve opened that channel up to anyone with an iCloud login where as Facebook are being choosy about who is invited to the party).
To make the web fast at scale, we want to make it easier to create documents that are fast-by-default.
Yes. This is a great thing to aspire towards. Lets build fast content… lets build in HTML.
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.
Okay, I can see the benefits of this approach. Taking on the problem of a slow web can be daunting so it makes sense to find a chunk and work out from there. Having said that, all of the work you do on this chunk needs to be able to integrate and work with the other chunks moving forwards, so an eye must be kept to ensure we don’t paint ourselves into a corner.
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.
Yes. Lets just build stuff in HTML and make the content available. Woot, we’re on the right track!
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?
Wait what? We’re using a subset of HTML? Which parts of HTML are we going to leave out? Lists? Definitions lists? Tables? the head, title, body? Divs? Horizontal rules? IMG tags?
Alright well I went and looked and found a list of what is/n’t included here.
I would hesitate to say, as 99.99% rule of thumb that any page or website created using HTML alone (no CSS or JS and not being stupid with loading images that are 84mb in size) you would have GREEN A+ marks across the board on any performance tests.
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.
HTML is build on existing web technologies, and the documents written in it render is all modern web browsers and web views. I don’t get what the AMP HTML is going to do to make that faster.
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.
I love this. Regardless of my confusion about the proposal I’m really happy to see that they are opening this up and starting an open conversation with the people that are building sites. Kudos for that effort.
One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
Huge call, but yeah that’s a fair thing. And I totally agree with the sentiment that websites should not need JS for users to access the content. Content first, lets not worry about the JS to be able to read the content.
JavaScript is the core building block for advanced web apps, but for static content it may not always be required: for a headline, some text and an image you do not need JS.
I couldn’t agree more. The more sites we build without the use of Javascript the better performance we will see across the board.
And yet the article goes on to say…
But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation. If AMP HTML provided the right custom elements, we might be able to get rid of arbitrary JavaScript for these documents altogether.
So it seems that you shouldn’t use Javascript to deliver your content with the exception of the javascript you need to let AMP work.
Here’s the head of the example HTML document provided on the Github page(https://github.com/ampproject/amphtml#how-does-amp-html-work)
<!doctype html><html ⚡><head><meta charset=“utf-8”><link rel=“canonical” href=“hello-world.html” ><meta name=“viewport” content=“width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui”><script src=“https://cdn.ampproject.org/v0.js” async></script><style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript></head><body>Hello World!</body></html>
Also from the Github page:
This allows the AMP library to include:
The AMP JS library, that manages the loading of external resources to ensure a fast rendering of the page.
So to ensure that you have faster rendering of the webpage here’s an external JS Library to serve your static content… that just seems weird to me.
The next few sections of the article talk about allowing CSS to style the static content the way you want, and that Ad’s and Analytics are bad for performance so they’re going to not allow any of these to be included if they are done so with Javascript.
AMP HTML is taking the following approach to analytics: so-called “tracking pixels” can be embedded into AMP documents as long as they don’t use JavaScript. They typically come with a no script 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.
In that they seem to show that they will support other Analytics providers (Google Analytics would be a given I think, and they’ve teamed up with Adobe Analytics as well) but only through a single interface using the AMP HTML system. I’m not sure how this then ties into your actual site analytics but I’m sure that will be cleared up in subsequent posts.
We’ve taken first steps to make ads in AMP HTML better, but we aren’t done yet. AMP HTML doesn’t allow JavaScript so ads cannot be directly embedded – instead they live in sandboxed iframes with no access to the primary document. Relying on iframes solves some of the worst performance pitfalls with ads, in particular with respect to 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.
It’s good to see that they’ve flagged Ad’s as a massive issue, however I don’t believe that including them via iFrames is any kind of solution moving forward. Looking at how Am I Responsive performs, and things like Social Sharing widgets it’s a burden rather than a suitable performant solution.
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.
That’s great news, you can’t really argue with great performance metrics.
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 tag, but they need to be conservative about this mechanism because pre rendering can be expensive.
This is concerning. If this is going to happen through Search results does that mean that you could have several pages pre-rendering even though you will only visit one of them… or maybe none of them?
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.
Great for perceived performance, but could be an issue with additional downloads when you’re not going to viewing the pages in the end. Maybe the fact that they’re so small won’t matter… but it’s certainly something to be aware of.
With all of these techniques in place, AMP HTML documents can be loaded with a small set of HTTP requests: the document itself, custom fonts (if used) and what we call the AMP JavaScript library that implements the AMP custom elements and resource loading.
For me this is loading one thing too many… the AMP JS library. Surely the document itself is going to be faster than loading a library to try and make it load faster.
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.
This is cool. There might be some issues with updating the cached version of the pages but that will show in time. Being on the Google Cache will make sure that your users get content super fast so that is one of the biggest wins I think.
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.
I’m not sure if this is solving anything at the moment that we’re not already fixing with something like responsive images. Sure it doesn’t have full support across all browsers but it will fall back to the smallest image size (if set up correctly).
They finish with…
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.
At the end of the day I love that they’re being open and collaborative. I fundamentally disagree that the correct path to a faster website lies with requiring Javascript and creating new HTML elements that will only work when that Javascript is available.
What do you think?
