Render-Blocking Resources: Finding and Eliminating Them
Render-blocking resources are head scripts without async/defer and stylesheets that match the current device — the exact criteria Lighthouse flags. Five steps to find and eliminate them.
A render-blocking resource is a script or stylesheet that stops the browser from painting anything to the screen until it finishes downloading and, for scripts, executing — and Lighthouse’s own criteria are specific: a script tag in the head without a defer or async attribute, or a stylesheet link without a media attribute that excludes the current device. Fixing them is mostly a matter of moving critical code inline, deferring the rest, and being disciplined about which CSS actually needs to load before first paint.
The audit used to be its own line item in Lighthouse; as of Lighthouse 13, the same detection moved into the broader “Render-blocking requests” insight, but the underlying rules for what gets flagged haven’t changed.
What exactly makes a script or stylesheet render-blocking?
The browser builds the page in a specific order: parse HTML, encounter a resource reference, decide whether it can keep painting or has to stop and wait. Two resource types routinely make it wait.
A <script> tag blocks rendering when it’s placed in the <head>, has no defer attribute, and has no async attribute. Without one of those two attributes, the parser has to pause, fetch the script, execute it, and only then continue building the page — because the script could theoretically use document.write to change what comes next.
A <link rel="stylesheet"> tag blocks rendering unless it has a disabled attribute (which stops the browser from downloading it at all) or a media attribute that doesn’t match the current device. A stylesheet marked media="print" won’t block a standard page render; one marked media="all", or with no media attribute at all, will.
How do you find which resources on your page are render-blocking?
Start with PageSpeed Insights or a local Lighthouse run — both list the exact URLs flagged, in the Opportunities section of the report. That tells you what’s blocking, but not what’s actually needed for the first paint versus what’s dead weight.
The Coverage tab in Chrome DevTools answers that second question. Load the page with Coverage recording, and it reports, file by file, how much of each CSS and JS file was used versus loaded. Code marked green was used for the current page’s rendering and core functionality; code marked red wasn’t. That distinction determines what gets inlined, what gets deferred, and what gets deleted outright.
| Fix | Applies to | What it does |
|---|---|---|
| Inline critical CSS | Above-the-fold styles | Removes the network round-trip for styles needed at first paint |
| defer / async attribute | Scripts not needed immediately | Lets the parser continue instead of waiting on script download and execution |
| Preload + media swap | Non-critical CSS | Loads the stylesheet without blocking, applies it once ready |
| Media-attribute split | Print or narrow-viewport stylesheets | Browser only blocks on stylesheets that actually match the current device |
| Remove unused code | Anything Coverage marks red across every page it’s tested on | Cuts payload size outright instead of just deferring the cost |
How do you eliminate render-blocking resources, step by step?
Once the Coverage tab has separated critical from non-critical code, the fix sequence is mechanical.
Five steps to eliminate render-blocking resources
- Step 1 — Run the DevTools Coverage tab to separate the CSS and JS your first paint actually needs from everything that’s just riding along.
- Step 2 — Inline critical CSS for above-the-fold content directly into a
<style>block in the document head. - Step 3 — Defer or async non-critical scripts so the HTML parser doesn’t stop to wait for something the initial render doesn’t need.
- Step 4 — Load the remaining CSS asynchronously, typically with a
rel="preload"link that swaps to a full stylesheet once downloaded. - Step 5 — Split stylesheets by media query so print styles and rarely-matched breakpoints stop competing with the main render path.
On WordPress specifically, this is rarely a hand-written fix — a caching or performance plugin that supports critical CSS generation and script deferral handles steps 2 through 4 for most themes, though it’s still worth spot-checking the Coverage tab afterward, since automated critical-CSS generators sometimes miss dynamically injected content.
What mistakes make render-blocking fixes backfire?
- Deferring a script that sets layout-critical variables. If a script calculates something the initial CSS depends on, deferring it can cause a visible layout jump once it finally runs — check Cumulative Layout Shift after any defer change, not just Largest Contentful Paint.
- Inlining the entire stylesheet instead of just the critical subset. This bloats the HTML document and forfeits the browser’s ability to cache the CSS file separately across pages, often making repeat visits slower even as the first visit gets faster.
- Using async on scripts that depend on execution order. Async scripts run as soon as they’re downloaded, with no guaranteed order relative to other async scripts — fine for independent analytics tags, risky for anything that expects a specific library to have already loaded.
- Forgetting mobile-specific stylesheets in the media-query split. A stylesheet scoped to a mobile breakpoint still blocks render on mobile devices even if it’s harmless on desktop — test Coverage and Lighthouse on both device profiles, not just desktop.
- Not re-testing after a plugin or theme update. Performance plugins that auto-generate critical CSS can silently stop working after a theme change, leaving the site back where it started without an obvious symptom.
Frequently asked questions
What exactly counts as a render-blocking resource?
Lighthouse flags a script tag as render-blocking when it sits in the head without a defer or async attribute. It flags a stylesheet link as render-blocking when it lacks a disabled attribute and its media attribute matches the current device, with media=”all” counting as a match.
Does eliminating render-blocking resources directly improve rankings?
It improves Largest Contentful Paint and, often, Cumulative Layout Shift, both of which feed into Core Web Vitals as part of Google’s page experience signals. Page experience is one input among many, not a guaranteed ranking jump, but it’s a real and measurable one.
Is inlining all CSS in the head always the right fix?
No. Inlining should be limited to the CSS required for above-the-fold content. Inlining an entire site’s stylesheet defeats the purpose — it grows the HTML payload and removes the browser’s ability to cache that CSS separately across page loads.
What’s the difference between defer and async on a script tag?
Both let the HTML parser continue instead of waiting on the script to download. defer waits until the document is fully parsed before executing the script, preserving order; async executes the script the moment it finishes downloading, which can be sooner but doesn’t guarantee execution order between multiple async scripts.
Sources
- Eliminate render-blocking resources — Chrome for Developers
- Core Web Vitals: The Complete Guide
- Technical SEO: The Complete Working Guide
- CDNs and SEO: When They Help and When They Hurt
- Does Hosting Affect SEO? What Actually Changes
- Why Your Mobile Score Is Far Worse Than Desktop
Want this done on your site?
Every PalV’s DM engagement starts with a free audit of your actual website — a 12-point
crawl covering what is blocking indexation, on-page gaps against your primary keywords, speed
findings, and the three to five fixes worth making first. Delivered in two working days. No
payment details, and the findings are yours whether you hire us or not.
