Thoughts on AMP

April 19th, 2019
amp, tech
(I work on ads at Google, which involves working closely with some AMP folks. These are all my views and not theirs or my employer's)

AMP is a way of writing web pages using a subset of HTML and CSS, plus some open source Javascript libraries. It has two main properties that allow it to be perform very well under some circumstances:

  • It doesn't allow many inefficient things that regular pages can do. You can't include an image tag without specifying its size, you can't write horribly performing javascript that blocks the UI thread and locks the page, you can only use CSS transitions that can be GPU-accelerated, etc.

  • It's designed for pre-rendering. The AMP JS knows when it's being speculatively rendered and prioritizes the most important and cheapest things. Additionally, this pre-rendering can happen in a privacy-preserving way

This is a really good fit for the case AMP was designed for: very fast loading when you click through from search results. This is a major use case in general and especially for Google. In order to provide this, however, AMP is fundamentally dependent on its javascript library, or 'runtime'. The runtime schedules the loading of everything on the page, tries to prioritize content that will be viewed soon, understands whether it's in prendering mode, etc.

As you might guess from this site and others I've made I really don't like the AMP approach. I hand-code my sites with simple HTML and minimal inlined CSS. Javascript is for progressive enhancement and implementing features. Having Javascript in the critical path of rendering or loading, as AMP has to do, is strongly at odds with the goal of fast and responsive sites.

In the non-preloaded case, taking a random post here, I see a median speed index of 1.611s on non-AMP but 2.051s on AMP. In both cases the HTML loads in ~400ms, but the HTML version can paint the HTML right away while the AMP version is still waiting on JS. Then the AMP version spends 600ms downloading and executing the AMP runtime and extension scripts. Once AMP has loaded it's smarter than the HTML version about what to load, deprioritizing below the fold resources, but it's already too far behind to catch up. The HTML page is fully loaded in about the time it takes the AMP page to finish rendering above the fold.

On the other hand, that's not most sites on the web. I see all sorts of Javascript frameworks and libraries, huge external stylesheets, giant images that the browser can't tell are well below the fold, complex asynchronous loading, etc. Most sites really are a lot faster and more responsive as AMP, and this improves my experience of using the web.

One way to look at this is that I want the web to be declarative: sites should describe how they should look and act. This is how HTML and CSS work, while in Javascript you tell the browser what to do. The AMP spec dramatically expands the range of what a site can do declaratively, but only if you think of the AMP runtime as part of the platform. Ideally I'd like to see the key things AMP provides made available actually as part of the platform, without the dependence on JS libraries. This could look totally different from AMP, but AMP is still very useful in that the project lets you see what features site-owners would need from something like this for it to be useful.

Comment via: facebook, substack

Recent posts on blogs I like:

On Apologizing To Kids

Everyone is so weird about apologizing to children.

via Thing of Things August 25, 2025

Against the Teapot Hold in Contra Dancing

The teapot hold is the most dangerous common contra dancing figure, so I’ve been avoiding it. The teapot hold, sometimes called a "courtesy turn hold,” requires one dancer to connect with their hand behind their back. When I realized I could avoid put…

via Emma Azelborn August 25, 2025

Little Puppy

She's very little and she likes to do stuff with me. She also likes to bark around and run around and jump around. She also likes to go to places with me and that's all I have.

via Nora Wise's Blog Posts August 23, 2025

more     (via openring)