Performance
Waterfall
Waterfall is a chart of every request a page makes, plotted along a time axis. It shows when each starts, how long its phases take, and what waited on what.
How it is measured
Open the DevTools Network panel or a WebPageTest result. Each row is a request, and the bar's segments are queueing, DNS, connect, SSL, waiting, and content download. Vertical lines mark events such as Start Render, DOMContentLoaded, and load.
Read it for chains: a CSS file that imports another that loads a font, or a script that injects another script. A stair-step shape means each request is discovered only after the one before has finished.
Worked example
A landing page's waterfall shows HTML finishing at 0.6 s and `main.css` at 1.1 s. The CSS references a font that runs from 1.2 s to 1.9 s and a hero image, set as a CSS background, that runs from 1.2 s to 2.8 s. Start Render waits until 1.9 s.
Preloading the font and image from the HTML moves their start to 0.65 s. Start Render lands at 1.2 s and LCP at 1.9 s.
How it differs
A waterfall shows order and dependency. A render-blocking audit tells you which entries in it hold up the first paint. A waterfall does not give aggregate numbers such as total bytes, and a short chart can still hide a busy main thread.
Common errors
Reading only the longest bar. Testing with the cache on. Ignoring the gaps between bars, which are often script execution. Comparing waterfalls made under different throttling. Reading a single run. Forgetting that requests after load matter for later interactions.
In practice
Capture a waterfall on a throttled mobile profile for your top landing page. Find the first stair-step chain and cut it with a preload, a preconnect, or by inlining. Run it again and compare the Start Render line.