Render-blocking resources delay initial rendering when the browser must fetch or process them before it can paint the page’s first useful view.
Locate the critical path
Stylesheets and synchronous scripts can block rendering when the browser needs them before building or painting the page. The right response depends on whether the resource is required for the initial view. Removing a request from a report without preserving the required styles or behaviour merely relocates the problem.
How to inspect it
Capture a page-load trace and identify which resources precede first render, which are actually used above the fold, and whether server response or main-thread work dominates the delay. Test on a cold cache and a representative connection. Lab evidence diagnoses the path; field data shows whether visitors experience it.
How to implement or improve it
Inline or prioritise only the small critical CSS needed for the initial view, defer non-critical code when it is safe, and reduce unused code at the source. After each change, verify visual completeness, keyboard behaviour, error-free interaction and no new layout shift.
Limits and common mistakes
The common mistake is deferring every script or stylesheet. Critical resources are critical because the initial page needs them; make the dependency smaller and intentional instead.
Triage starts with a waterfall and a trace, not with a blanket “defer JavaScript” rule. Identify the first useful visual state, list the CSS, fonts and scripts needed to create it, and separate that small set from assets requested later. A stylesheet that defines the initial navigation may be critical; a carousel library below the fold is not. Inspect request priority, response time, unused bytes and main-thread tasks. For implementation, reduce or split unused style at the source, preload only a resource that the first view truly needs, and defer an asset only after checking that the initial page remains styled and interactive. Retest cold cache, a constrained connection and keyboard navigation. If a font swap changes line wrapping, record the layout effect as well as the load timing. The result to verify is a complete usable first view, not merely a smaller warning count.
Concrete example: a product listing loads one global stylesheet, a small header stylesheet, a web font, a sorting component and a below-fold gallery. In the waterfall, confirm that the first two stylesheets are actually used before first paint; they may be candidates for a reduced critical bundle. The gallery script should not delay the header and product grid if it is not visible. Do not inline the entire global stylesheet: it duplicates bytes and makes caching harder. Instead, extract only rules required for the initial view, load the main stylesheet normally, and test the transition when it arrives. Re-run the waterfall after deployment and inspect for flash of unstyled text, missing focus outlines and layout shift. A change is accepted only when the page paints correctly and later interactions remain functional.