Critical rendering path
The exact chain of work a browser must finish (HTML, CSS, layout, paint) before anything at all appears on screen.
See it
What it is
The critical rendering path is the fixed chain of work between 'bytes arrived' and 'pixels on screen': parse HTML into the DOM, parse CSS into the CSSOM, run any scripts that get in the way, combine DOM and CSSOM into a render tree, compute layout, then paint. Nothing shows until that chain completes at least once. Every millisecond you shave off it is a millisecond earlier your user sees something.
Reach for it as a diagnostic frame when First Contentful Paint or LCP is bad and you don't know why. The three levers are always the same: send fewer critical bytes (inline only above-the-fold CSS, defer the rest), shorten the request chain (don't make CSS import CSS that imports a font), and get scripts out of the way with defer, async, or deletion.
The classic misconception: people optimize total page weight when the critical path only cares about the blocking subset. A 3MB page can paint fast if its first screen needs 20KB of CSS and zero blocking JS. A 300KB page can look frozen if one synchronous script sits in the head. Size of the whole is not the number that matters.
Ask AI for it
Audit and shorten the critical rendering path for this page. Inline the CSS needed for the first screen into a style tag in the head and load the rest with a non-blocking preload swap; add defer to every script tag that is not required for first paint; move third-party tags below the fold or behind an interaction; add preconnect hints for any origin the first screen depends on. List the remaining render-blocking requests in load order with their transfer sizes, then report the before and after count of blocking resources.