Learning on Web Dev Open is free for all.

System Design & Performance > Where the milliseconds goWhere the milliseconds go
Phase 06Where the milliseconds go298 of 434

Where the milliseconds go

A real waterfall drawn to scale. Find the critical path, write the plan, then defend it against a model briefed to attack every line.

Build50 minAI adversary
Phase 06 · Lesson 02

Where the milliseconds go

AI: adversary~50 min

Two point one seconds to interactive, and not one of them is spent on the thing the page is for.

Beat 1: Build it

The chart below is a network waterfall for a blog post page, drawn to scale at one pixel per five milliseconds. Read it before you optimise anything. A waterfall is a dependency graph wearing a costume: bars that start at the same x can happen at once, and a bar that starts where another ends is telling you it could not begin until that one finished. Every fix in performance work is either "make this bar shorter" or, far more often, "make this bar start earlier".

Work out the critical path, the chain of bars that, if you shortened any one of them, would move the finish line, and separate it from the bars that are merely present. Then write the plan: what you would change, in what order, and how many milliseconds each change is worth.

Now use the model as an adversary. Paste your plan and instruct it to argue that every item makes the page worse, then keep only the objections that survive contact with the chart. Some of them will be real: preconnect to too many origins costs more than it saves, a font swap trades invisible text for a visible reflow, and batching three requests into one endpoint can create a slow endpoint that nothing can cache. A plan you have defended is worth more than a plan you have listed.

Ask the community

Loading…

Workbench

You should now be able to

  • Identify a critical path in a network waterfall
  • Distinguish making a bar shorter from making it start earlier
  • Defend an optimisation plan against specific objections
Ask the community

Loading…