Performance
Critical rendering path
Critical rendering path is the sequence of steps the browser must finish before anything shows on screen. It runs from the first HTML bytes through CSS, blocking scripts, and fonts to the first paint.
How it is measured
Look at the trace: HTML parse builds the DOM, CSS builds the CSSOM, both combine into the render tree, then layout and paint run. Measure the time from navigation start to First Contentful Paint, and count which resources sit in between.
A resource is on the path if the browser will not paint until it arrives. Stylesheets in the head and synchronous scripts are the common cases. Async and deferred scripts, images below the fold, and late fonts are not.
Worked example
A brochure site has an HTML response at 220 ms, two CSS files finishing at 740 ms and 980 ms, and a synchronous analytics script finishing at 1,200 ms. FCP lands at 1,260 ms. Marking the script `defer` and merging the CSS moves FCP to 820 ms.
The hero font still loads later and swaps in at 1,100 ms. Because it is not on the path, it does not move FCP, though it does show as a layout shift of 0.02 until font-display is set.
How it differs
The critical rendering path is the whole dependency chain. Critical CSS is one tactic that shortens it. Render-blocking resources are the individual items on it. Shortening the path means fewer, smaller, earlier items, not necessarily fewer total bytes on the page.
Common errors
Optimizing total page weight while the path stays long. Putting scripts in the head without defer. Chaining CSS with `@import`. Hiding the page behind an A/B test snippet that blocks paint. Preloading everything, which makes real critical items compete for bandwidth.
In practice
Open a performance trace of your slowest template and list everything before first paint. Defer or async scripts, inline or trim CSS, and preload only the one or two assets that truly gate the first view. Retest FCP and LCP after each change so you know which one helped.