AMPs and websites in the age of the Service Worker

AMP HTML is a new way to publish static content on the web with reliable fast performance built on existing web technologies. It is very focused on this use case and thus not a direct good fit to build general purpose websites or even web apps. In fact, the reason why it can beat more generic approaches to performance is because it is good at only one thing: content like news articles, blog post or recipes. Having said that, AMP HTML can play an important role in transforming today’s websites to be faster, more engaging web apps.

This article explains our vision of how AMP relates to websites. But first, if you haven’t tried AMP yet, watch this short video to get an impression how it transforms the user experience of content consumption on the web:

Addy Osmani showing Google’s AMP demo.

Google, Twitter or feed readers like Nuzzel are planning to provide experiences similar to the Google Search demo above.

AMP might, however, play an important role in transforming websites of AMP producing publishers: The idea is that homepages like nytimes.com and buzzfeed.com would be apps showing AMP documents while applicable permalink pages (the actual articles) are AMP documents. Wouldn’t it be great if all the clicks to articles from the homepage of news organization would show the article instantly — just like in the Google Search demo above? This could become the new normal.

Do we need both an AMP and a regular HTML version of a document?

One of the most common questions about AMP HTML is: “So, do we need to make both an AMP version of a document and a regular HTML version? What about mobile and desktop?” As of this point we’d give the following answer:

1. AMP HTML works great on desktop. It has responsive design baked in beyond supporting standard CSS techniques.
2. We just launched the AMP project two weeks ago as a developer preview with the explicit intent to gather feedback and then further evolve the platform. It may still be a good idea to hedge one’s bets and not go all in on AMP HTML.

Service Workers to the rescue

But for those of you living on the edge, you could make all your applicable permalink pages be AMP HTML and implement the following pattern:

1. Your website is a web app that displays AMP HTML documents.
2. When users click e.g. on a link on Twitter to one of those AMP HTML documents and they have never been to your site before all that happens is that the AMP HTML document is being displayed…
3. …and a Service Worker is installed which fetches and caches your app shell.
4. Then next time a user clicks on a link to a permalink to your page the Service Worker intercepts that request and immediately returns the app shell which then proceeds to display the AMP HTML document. (Related AMP issue)

With this method users get the super fast / instant loading of AMP but on subsequent visits to a site they also get the full app experience at the same speed.