The Guardian breaks news at 1000ms

https://learning.oreilly.com/case-studies/mobile/the-guardian-breaks-news-at-10/9781491991336-video307660


  • The old version of guardian.com was not responsive and took 10 seconds to load on average.
  • Used these guidelines across the org to drive more awareness & accountability during the migration to a new responsive version:
  • Load times are measured as perceived load times (time until paint).
  • Their target budget was 1000ms, but a lot of that is spent on networking that the app doesn’t have control over. The real target was more like 400ms.
  • For a guardian.com page, nothing is as important as the content, so using an entirely server-side rendered system causes a lot of unnecessary blocking waits, which might impact both performance and reliability/resiliency unnecessarily:
  • The new version only loads the content in the critical path; everything else is async.
  • Browsers stream HTML, but block when they hit a link/script tag, and wait until that resource is downloaded.
  • CSS can’t be streamed, so the browser waits until the entire thing has downloaded and then builds the CSS object model.
  • Their solution was to inline all critical CSS in <head>, and have everything else be loaded async at the bottom of the initial payload.
  • Ditto for fonts.
  • localStorage is used to cache these resources, so on subsequent page loads, they can be loaded along with the critical resources at the top of the page.
    • Can’t use HTTP caching for this because it doesn’t provide enough flexibility to implement this two-pronged “if cached load the top of the page, if not, load at the bottom of the page” approach.
  • TL;DR: A lot of real eng work was needed to get the content loaded and rendered within 1000ms.

Look Up

  • Beacon API / RFC
  • HTTP/2 + server push
  • TCP congestion window
  • Service workers
  • High performance browser networking - Ilya Gregorik
  • Render path / render blocking
  • ngx_pagespeed
  • Fastly + onCookie
Edit