• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • 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:

    A Big Problem With The Going To Bed Book

    One day my dad was reading this book called the "Going to Bed Book" to my sister Nora. The book is basically about a bunch of animals who are getting ready for bed on a boat. They go down the stairs, take a bath, hang their towels on the wall, find…

    via Lily Wise's Blog Posts September 18, 2023

    Investing in boundaries with young kids

    Putting in some work to get the behavior you want The post Investing in boundaries with young kids appeared first on Otherwise.

    via Otherwise August 15, 2023

    Self-driving car bets

    This month I lost a bunch of bets. Back in early 2016 I bet at even odds that self-driving ride sharing would be available in 10 US cities by July 2023. Then I made similar bets a dozen times because everyone disagreed with me. The first deployment to pot…

    via The sideways view July 29, 2023

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact