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.
Where the milliseconds go
Two point one seconds to interactive, and not one of them is spent on the thing the page is for.
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.
Loading…
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
Loading…