Render-Blocking Resources How to Find and Fix Them
search console referenceWelcome bro. Render-blocking resources are files, usually CSS and scripts, that the browser must load before it can show anything on screen. This guide explains which files block, how to spot them, and the fixes the tools recommend, in plain words.
- CSS and scripts
- defer, async, media
- how to test
| file in the head | blocks first paint? | fix |
|---|---|---|
| style.css | yes | inline critical CSS |
| slider.js (no attribute) | yes | add defer |
| analytics.js (async) | no | keep |
| print.css (media=print) | no | keep |
// example data for a bakery site in Leeds. The rules behind the verdicts are from Lighthouse and MDN documentation.
What Render-Blocking Resources Are
They are files the browser must fetch and process before it paints the page. The usual suspects are stylesheets and scripts in the head of your HTML.
When a visitor opens your page, the browser reads the HTML from top to bottom. When it meets a file it must wait for, the screen stays blank. web.dev puts it this way for CSS: “CSS files are render-blocking resources: they must be loaded and processed before the browser renders the page.” Oversized stylesheets delay First Contentful Paint, which is the moment the first content appears.
Lighthouse, the free audit built into Chrome, lists these under its render-blocking audit. Its goal, in its own words, is to lessen their impact by inlining critical code, deferring non-critical code and removing unused code. Chrome’s page notes that as of Lighthouse 13 this audit moved into the Render-blocking requests insight, and the old page is kept as reference. This links closely to loading speed, which I cover in my guide to Largest Contentful Paint.
Which Files Actually Block Rendering
Stylesheets without a matching media attribute, and scripts in the head without defer or async, are flagged by Lighthouse.
| resource | flagged when | not flagged when |
|---|---|---|
| Script | a script in the head has no defer or async | it has defer or async |
| Stylesheet | a link rel=stylesheet has no media attribute matching the device (media=all counts as blocking) | it is disabled, or its media attribute does not match the user’s device |
// source: Chrome for Developers, Lighthouse “Eliminate render-blocking resources”.
MDN adds a useful subtlety about scripts. A script without type="module", async or defer blocks parsing, not rendering by default, and only scripts in the document head can block rendering. In everyday terms: a plain script stops the browser reading further HTML until it has run. Tools and people both loosely call that “render-blocking”, so I use the Lighthouse definition for the audit.
Defer, Async and Plain Scripts
defer waits until the page is parsed and keeps order. async runs as soon as it is downloaded, in any order. A plain script stops everything.
| attribute | download | runs | order kept? |
|---|---|---|---|
| none | immediately, blocks parsing | immediately | document order |
| async | in parallel with parsing | as soon as downloaded | no guarantee |
| defer | in parallel with parsing | after parsing, before DOMContentLoaded | document order |
// source: MDN Web Docs, the script element.
MDN also says both attributes only work on external scripts with a src. They have no effect on inline scripts. Module scripts defer by default, so adding defer to them does nothing.
The Fixes Google’s Tools Recommend
Inline the critical CSS, defer the rest, add defer or async to scripts, and delete code you never use.
Defer or Async Non-Critical Scripts
Keep non-critical code in an external file and add async or defer. Move critical code into an inline script, and remove code that is never used.
Inline Critical CSS
Put the rules needed for the first screen into a <style> block in the head, and load the rest without blocking.
Split by Media Query
Split styles into files by media query and set a media attribute on each link, so only the matching stylesheet blocks rendering.
Remove and Minify
Delete unused code and minify CSS. The Coverage tab in Chrome DevTools marks critical code green and non-critical red.
For loading non-critical CSS without blocking, web.dev shows a rel="preload" pattern that switches the link to a stylesheet once it loads, with a noscript fallback. It also warns this technique may lead to bugs if not implemented properly, that most sites can reach the recommended performance targets without it, and that production sites should use a CSS-deferring function because inline onload code might not be allowed under some Content Security Policies. So treat it as an advanced step.
Fixing It on a WordPress Site
Most WordPress sites fix this with a performance plugin, because themes and plugins add the files for you.
Chrome’s Lighthouse page lists WordPress plugins that inline critical assets or defer resources, among the platform options. I do not name a favorite here, because I have not tested one for this article and I do not want to invent a verdict. My general rule is to try one change at a time, on a staging copy, and click through the whole site afterward, because deferring the wrong script can break a menu or a form.
If you run WordPress, also read my guide on Core Web Vitals for WordPress. And note that a slow server start is a separate problem, covered in time to first byte.
How to Fix Render-Blocking Resources
Find the files, decide which are critical, change one thing at a time and re-test. Six steps.
- Run PageSpeed Insights or Lighthouse. Note the render-blocking files it lists.
- Find the critical code. Use the Coverage tab in DevTools. Green is critical, red is not.
- Defer scripts. Add
deferto scripts that need the page parsed, andasyncto independent ones. - Handle the CSS. Inline the critical rules or split stylesheets by media query.
- Remove what you do not use. Old plugin scripts and unused CSS are the easiest wins.
- Test the page like a visitor. Click the menu, the form, the slider. Then re-run the audit.
Run audit
list blocking files
Find critical code
DevTools Coverage
Defer scripts
defer or async
Tame the CSS
inline or media split
Remove unused
and minify
Test and re-audit
click everything
// the order is mine. Each fix comes from the Lighthouse, MDN and web.dev pages listed in Sources.
Mistakes and Their Fixes
Most mistakes break a page quietly. That is why testing matters more than the audit score.
Async on Dependent Scripts
- A library and its plugin both set to async
Fix: MDN says async gives no order guarantee. Use defer when scripts depend on each other.
Defer on Inline Scripts
- defer added to a script with no src
Fix: it has no effect on inline classic scripts. Move the code to a file, or leave it inline on purpose.
Inlining Too Much CSS
- The whole stylesheet pasted into the head
Fix: inline only the critical rules, as the Lighthouse page advises.
Moving the Link to the Bottom
- A stylesheet link placed at the end of the page
Fix: web.dev says it does not fully solve blocking, because the browser still prioritizes the stylesheet.
How to Check It Worked
The audit should stop listing the files, and the page should still look and work the same.
- Re-run Lighthouse or PageSpeed Insights and check the file list got shorter.
- Compare First Contentful Paint and LCP before and after. web.dev’s demo saw First Contentful Paint drop by 0.2 seconds, about 20 percent, but your result will differ.
- Test the menu, forms and sliders on desktop and a real phone.
- Watch the Core Web Vitals report in Search Console for field improvement over the following weeks.
This is a classic technical SEO job. A cheap SEO company like mine can do the careful testing that automated plugins skip. See also my page experience guide.
Render-Blocking Questions Answered
Is all CSS render-blocking?
web.dev says CSS files are render-blocking resources. Lighthouse does not flag stylesheets that are disabled or whose media attribute does not match the device.
Should I use defer or async?
Use defer when order matters, because defer scripts run in document order after parsing. Use async for independent scripts, because async runs as soon as downloaded in no guaranteed order.
Do defer and async work on inline scripts?
No. MDN says they must not be used without a src attribute for classic scripts, because they would have no effect.
What is critical CSS?
The styles needed to paint the first screen. Lighthouse suggests inlining them in a style block in the head and loading the rest without blocking.
Will fixing this improve my rankings?
I cannot promise that. Faster loading helps visitors and feeds Core Web Vitals, but Google says relevance still comes first.
Send Me Your URL. I’ll Check Your Head Section.
One WhatsApp message is enough for a first look.
Sources and Last Check
- Chrome for Developers: Eliminate render-blocking resources (what is flagged, fixes)
- MDN Web Docs: the script element (async, defer, blocking)
- web.dev: Defer non-critical CSS (CSS blocks rendering, preload pattern, tradeoffs)
- web.dev: Web Vitals (background on loading metrics)
// last checked 11 Nov 2026. Example data is invented. web.dev’s own render-blocking article could not be opened this session, so nothing here relies on it. Fix order and WordPress testing advice are my experience and opinion.