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

Recent posts on blogs I like:

Somewhat Against Trans-Inclusive Language About Biological Sex

"People with vaginas"? Well, maybe

via Thing of Things April 25, 2024

Clarendon Postmortem

I posted a postmortem of a community I worked to help build, Clarendon, in Cambridge MA, over at Supernuclear.

via Home March 19, 2024

How web bloat impacts users with slow devices

In 2017, we looked at how web bloat affects users with slow connections. Even in the U.S., many users didn't have broadband speeds, making much of the web difficult to use. It's still the case that many users don't have broadband speeds, both …

via Posts on March 16, 2024

more     (via openring)