Performance
Render-Blocking Resources
CSS and JavaScript the browser must download and process before it can paint anything, holding the page blank and inflating load metrics.
When a browser meets a stylesheet or a synchronous script in the head of a page, it stops. Nothing paints until those files are downloaded, parsed, and executed, because rendering an unstyled page and then restyling it would be worse. Every such file is render-blocking: a gate between the visitor and the first pixel.
This is routinely the largest single cause of a slow Largest Contentful Paint. The page is not heavy so much as queued behind its own resources: a framework bundle here, three stylesheets there, a font loader in front of everything. On fast fiber it is barely visible; on a mid-range phone over cellular, it is seconds of blank screen.
The fixes are well understood: inline the small amount of CSS the first screen needs, defer the rest, mark scripts defer or async, and ship less code in the first place. The discipline is keeping it fixed, because every added tag and dependency wants back onto the critical path. This is exactly the layer a performance pass audits first, since wins here move every metric downstream.