What Is Render-Blocking Resource?

Q: Does async or defer stop a script from blocking rendering?

Yes. A normal ` ` in the head pauses HTML parsing until it downloads and runs. Adding `async` lets it download without blocking the parser and run when ready, and `defer` runs it after parsing finishes, so neither blocks the first paint.

Written byFlavio Amiel Founder, Roborank

Updated July 15, 2026

A render-blocking resource is a file — typically a stylesheet or a synchronous script in the document head — that the browser must download and process before it can paint any content to the screen. Until every such resource is handled, the page stays visually blank, so these files directly delay First Contentful Paint.

Key Takeaways

Lighthouse flags two kinds of render-blocking URLs: <script> tags in the head without defer or async, and <link rel="stylesheet"> tags without a disabled attribute or a non-matching media query.
CSS is render-blocking by default because the browser will not paint until it has built the CSS Object Model from every stylesheet.
The three core fixes are inlining critical code, deferring non-critical resources, and removing unused code entirely.
A media attribute lets the browser skip blocking on stylesheets that do not match the current device, and async/defer stop scripts from blocking the parser.

How Render-Blocking Resources Work

A browser builds a page by parsing HTML into a DOM tree, then combining it with a CSS Object Model to paint pixels. Certain resources force the browser to pause that pipeline. When the parser reaches a plain <script> in the head, it stops, downloads the script, executes it, and only then resumes — because the script might modify the DOM it is about to build. Stylesheets are blocking for a different reason: the browser refuses to paint until it has the full CSS Object Model, since rendering first and styling second would cause a jarring flash of unstyled content. Either way, the visitor stares at a blank screen until the blocking work is done.

That blank window is exactly what First Contentful Paint measures. Every render-blocking resource on the critical path pushes FCP — and with it Largest Contentful Paint, a Core Web Vital — later in time. The performance goal, in Google’s words, is “to reduce the impact of these render-blocking URLs by inlining critical resources, deferring non-critical resources, and removing anything unused.”

The subtle part is that blocking is the default behavior, not an error. A stylesheet the page genuinely needs is still render-blocking; the work is to distinguish resources the first screen requires from those it does not, and to change how the latter load.

What Lighthouse Flags as Render-Blocking

Lighthouse’s audit identifies two specific patterns:

Scripts — <script> tags in the document head that lack a defer or async attribute. These pause HTML parsing until they download and run.
Stylesheets — <link rel="stylesheet"> tags without a disabled attribute or a device-specific media query. A stylesheet with media="all", or no media attribute, blocks the first paint.

The elimination techniques map onto those two categories. For scripts: inline the small amount of critical code, add async or defer to the rest, and delete unused code. For stylesheets: inline the above-the-fold CSS in a <style> block, load the remainder asynchronously (for example via a preload link), split styles by media query so a print or wide-screen sheet never blocks a phone, and minify what remains. Chrome DevTools’ Coverage tab colors used code green and unused code red, which makes the critical-versus-noncritical split concrete.

Example of a Render-Blocking Resource

Consider the canonical case Google documents: a single external stylesheet linked in the head, <link rel="stylesheet" href="styles.css">. Because it carries no media attribute, the browser treats it as media="all" and blocks the first paint on it. If that file is 100 KB and the connection is slow, the entire page waits on the full download before a single pixel appears, even though the header and hero section might only depend on a few kilobytes of those rules.

The documented fix is to split the sheet by intent. Google’s guidance shows moving device-specific rules into separate files with matching media queries — for instance <link rel="stylesheet" href="print.css" media="print"> and <link rel="stylesheet" href="mobile.css" media="(max-width: 600px)">. The browser still downloads all three, but it only blocks the first paint on the sheets whose media query matches the current device. On a phone in portrait, the print sheet no longer stands between the user and the first paint.

The lesson generalizes past this one file. Render-blocking is a property you assign, not a fixed fact about a resource. The same CSS can block or not block depending on whether it is inlined, deferred, or scoped with a media query. Fast pages are the ones whose authors decided, resource by resource, what the first screen actually needs — and let everything else load out of the way.

The thing people get wrong

The word people miss in "render-blocking" is default. A plain <link rel=\"stylesheet\"> or a plain <script> in the head is opt-out, not opt-in — the browser blocks on it unless you tell it otherwise. So the fix is almost never "delete the file," it is "change how it loads." I routinely see teams try to strip a stylesheet the design genuinely needs, break the layout, and give up, when the right move was a media attribute or moving the load off the critical path. Ask of each blocking resource: does the very first paint actually need this? If not, it should load async, deferred, or split by media query. Almost every above-the-fold win comes from reclassifying resources, not removing them.

Frequently Asked Questions

What is a render-blocking resource?

It is a file, usually a stylesheet or a synchronous script in the page head, that the browser must fully download and process before it can render any visible content. While the browser waits, the page stays blank, which delays First Contentful Paint and hurts perceived speed.

Why is CSS render-blocking?

The browser will not paint a page until it has constructed the CSS Object Model from every stylesheet, because applying styles later would cause a flash of unstyled content. So CSS blocks the first paint by design, and every stylesheet in the head adds to that wait.

How do I eliminate render-blocking resources?

Inline the critical CSS an above-the-fold view needs, load the rest asynchronously, add defer or async to non-critical scripts, split stylesheets with media attributes so off-device styles do not block, and remove unused code. Chrome DevTools’ Coverage tab shows what is actually used.

Does async or defer stop a script from blocking rendering?

Yes. A normal <script> in the head pauses HTML parsing until it downloads and runs. Adding async lets it download without blocking the parser and run when ready, and defer runs it after parsing finishes, so neither blocks the first paint.

The Bottom Line

A render-blocking resource is a gatekeeper the browser has to clear before showing anything. The goal is not to smash every gate but to decide which ones truly guard the first screen: keep those small and inline, and wave the rest through asynchronously. Get that triage right and the page paints in a fraction of the time without losing a single style or feature.

Sources

Eliminate render-blocking resources — Chrome for Developers (Lighthouse)
Render-blocking CSS — web.dev (Google)

Roborank does this

Roborank’s site audit spots the render-blocking scripts and stylesheets slowing your first paint, and shows which ones can be deferred or inlined.

Find what blocks your render →

Rank & Cash — the weekly SEO breakdown

One practical teardown a week on ranking in search and getting cited by AI. No fluff.