Render-Blocking Resources

Render-blocking resources are assets the browser must process before it can produce useful page pixels. Stylesheets and certain synchronous JavaScript can delay painting, increasing metrics such as First Contentful Paint (FCP) and potentially Largest Contentful Paint (LCP).

The browser builds the DOM from HTML and the CSSOM from stylesheets, then combines them to determine what can be rendered. External CSS is generally render-blocking because the browser needs applicable styles before safely painting styled content.

Classic synchronous `<script>` elements can also delay progress. A parser-blocking script can pause HTML parsing while the browser fetches and executes it, which may postpone discovery of later resources and delay rendering. JavaScript that changes the DOM or styles can also require additional work before pixels are produced.

Not every script blocks rendering in the same way. `async` scripts download independently and execute as soon as available, while `defer` scripts execute after HTML parsing and preserve document order. Module scripts are deferred by default unless their behavior is changed through other mechanisms.

Reducing blocking work involves identifying the critical rendering path rather than blindly making every resource asynchronous. Common techniques include inlining a small amount of critical CSS, removing unused CSS, splitting noncritical styles, deferring nonessential JavaScript, and using `preload` selectively for resources that are genuinely important to the initial view.

Key points

• External CSS commonly blocks rendering because styles are needed to construct the rendered presentation.
• Classic synchronous scripts can block HTML parsing and delay discovery and execution of later resources.
• `async` and `defer` change classic script loading behavior; `defer` preserves document order and waits for parsing to finish.
• Reducing render-blocking work can improve paint-based metrics such as FCP and can help LCP when critical content depends on the blocked work.
• Optimize the critical rendering path instead of indiscriminately removing every blocking resource.

Interview questions

How can render-blocking resources affect Core Web Vitals?

Resources on the critical rendering path can delay when the browser first displays meaningful pixels. That can increase FCP, and if the largest visible element depends on delayed CSS, JavaScript, fonts, or image discovery, LCP can also be affected. The actual impact depends on the page structure, network conditions, and which resources are needed for above-the-fold content.

What is the difference between `async` and `defer`?

Both let a classic external script download without pausing HTML parsing. An `async` script executes whenever its download finishes, so execution order among async scripts is not guaranteed. A `defer` script waits until HTML parsing is complete and deferred scripts execute in document order.

Why does CSS block rendering?

The browser needs CSS to determine the styling and layout of elements before it can reliably paint the page. External stylesheets therefore participate in the critical rendering path. Waiting for them can delay the first meaningful pixels, especially when stylesheets are large or numerous.

How would you diagnose and reduce render-blocking resources on a production site?

I would first use browser performance tooling and field or lab metrics to identify which requests delay the first paints. Then I would inspect the critical request chain, stylesheet size, script loading attributes, and resource priorities rather than simply counting blocked files. Typical changes include removing unused CSS, extracting critical styles, deferring nonessential scripts, and improving resource discovery. I would remeasure afterward because an optimization that reduces blocking can still hurt performance if it creates excessive network contention or delays a critical dependency.