Render-Blocking Resources
Render-blocking resources are CSS and JavaScript files the browser must finish before it can show anything. This guide explains exactly what Lighthouse flags, how to find your blockers, and the fixes in order: defer scripts, inline critical CSS, split styles by media, and remove unused code, with WordPress notes.
- What Lighthouse flags
- Find blockers
- Fix recipes
- WordPress plugin notes
<script src="a.js"> blocks <script src="b.js" defer> ok <script src="c.js" async> ok <link rel="stylesheet" href="s.css"> blocks <link ... media="print"> ok
Lighthouse flags scripts in the head with neither defer nor async and stylesheets without a matching media attribute (media=”all” still blocks). Fix them by inlining critical code, deferring the rest, splitting CSS by media and removing unused code. In WordPress, a performance plugin that defers JavaScript and inlines critical CSS is the usual route. Test after every change, because deferring can break features.
What render-blocking means
When a browser loads your page it builds the visible layout from HTML and CSS. A stylesheet in the head pauses that work until it is downloaded and read. A synchronous script in the head pauses it even more. Anything that delays the first paint this way is a render-blocking resource.
Blank screen too long
Visitors see nothing while files download. This hurts First Contentful Paint and LCP.
Show content first
Load what is needed for the first view immediately and everything else later.
What Lighthouse flags
The Lighthouse audit “Eliminate render-blocking resources” lists URLs that block first paint. As of Lighthouse 13 it has moved into the Render-blocking requests insight. It flags two kinds of resource:
| Type | Flagged when | Not flagged when |
|---|---|---|
| Script | A script in the head has neither defer nor async | It has defer or async |
| Stylesheet | A link rel=stylesheet is not disabled and its media does not specifically match the device (media=”all” counts) | Its media attribute does not match the current device |
The criteria are Lighthouse’s markup-based rules from its documentation. It does not describe other detection logic on that page.
Find your blockers
Start with the speed up WordPress guide if you have not set up caching yet, because render-blocking fixes build on a fast server (see TTFB).
Fixing scripts
- Move critical code inline into a small script tag, only if it is needed for the first view.
- Keep the rest external and add
deferorasync. - Remove unused code. Scripts for features you no longer use still cost time.
| Attribute | Behaviour | Use for |
|---|---|---|
| (none) | Blocks parsing while it downloads and runs | Rarely a good idea in the head |
| defer | Downloads in parallel, runs after parsing, keeps order | Scripts that depend on the page or on each other |
| async | Downloads in parallel, runs as soon as ready, any order | Independent scripts such as analytics |
The defer and async behaviour row is standard HTML behaviour (my own summary of how browsers work).
Fixing stylesheets
- Inline above-the-fold CSS in a style block in the head.
- Load the rest asynchronously using a preload link.
- Automate extraction of above-the-fold CSS with the Critical tool.
- Split by media query and add a media attribute so only matching stylesheets block the first paint.
- Minify the CSS.
Code examples
<!-- Script: do not block parsing --> <script src="/js/app.js" defer></script> <script src="/js/analytics.js" async></script> <!-- Stylesheet: only blocks on print --> <link rel="stylesheet" href="/css/print.css" media="print"> <!-- Critical CSS inline, rest loaded without blocking --> <style>/* critical above-the-fold rules */</style> <link rel="preload" href="/css/site.css" as="style" onload="this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="/css/site.css"></noscript>
Fix render-blocking step by step
Run PageSpeed Insights
Test mobile for a post and the home page. Save the list of blocking files.
See who owns each file
Most file names reveal the theme or plugin. Note which are essential.
Delete unused code
Disable plugins you do not need, and remove scripts from pages that do not use them.
Defer JavaScript
Use your performance plugin’s defer option, then exclude any script that breaks.
Handle CSS
Enable critical CSS or minify and combine carefully, then test the layout on mobile and desktop.
Check every important page
Menus, forms, sliders and checkout often break first. Test them, then re-run PageSpeed Insights.
Notes for WordPress sites
Lighthouse’s own documentation points WordPress and Joomla users to plugins that inline critical assets or defer less important resources.
- One optimisation plugin. Running two that both change scripts can break the site (my own advice).
- Exclude jQuery if needed. Many scripts depend on it; deferring it incorrectly breaks them.
- Page builders. They often add large CSS and JS files; use their built-in optimisation options.
- Cloudflare. Some Cloudflare features alter scripts; see Cloudflare SEO settings.
Troubleshooting
| Symptom | Likely cause (my own diagnosis) | Fix |
|---|---|---|
| Menu or slider stopped working | A deferred script loaded too late | Exclude that script from deferral |
| Unstyled flash on load | Incomplete critical CSS | Regenerate critical CSS |
| Score did not change | Blocking file still loaded elsewhere | Clear caches, retest |
| Layout shifts after change | Late CSS rules | Check CLS |
| Third-party script blocks | Added synchronously by a tag | Load it async or via a delayed tag |
Checklist
Scripts
- No sync scripts in the head
- Defer or async added
- Unused scripts removed
- Exclusions tested
CSS
- Critical CSS inlined
- Rest loaded without blocking
- Media attributes used
- Minified
Testing
- Mobile PageSpeed run
- Key pages checked
- Forms and menus work
- CLS unchanged
Safety
- Backup before changes
- One plugin at a time
- Staging first if possible
- Re-test after updates
What the sources do not say
Lighthouse documents which resources it flags and how to fix them, but it does not give a ranking benefit or a target number of blocking files. Google’s page experience guidance treats Core Web Vitals as the speed aspect used directly in ranking, not individual Lighthouse audits.
Key terms
- Critical CSS
- The minimum styles needed to show the first view.
- defer
- A script attribute that runs the script after parsing finishes.
- async
- A script attribute that runs the script as soon as it downloads.
- First paint
- The moment anything first appears on screen.
Common mistakes
Deferring everything blindly
It can break features.
Using two optimisation plugins
They conflict.
Inlining too much CSS
Bloats every page.
Ignoring unused code
The fastest file is no file.
Testing on desktop only
Mobile is slower.
Chasing a perfect score
Real users matter more.
Related guides
Render-blocking questions
What does Lighthouse flag as render-blocking?
Head scripts with neither defer nor async, and stylesheets whose media attribute does not specifically match the device.
Does media=”all” block rendering?
Yes, it counts as render-blocking.
What is the difference between defer and async?
Defer runs scripts after parsing in order; async runs each as soon as it downloads.
How do I find unused code?
Use the Coverage tab in Chrome DevTools: red marks unused code.
Should I inline all my CSS?
No. Inline only above-the-fold CSS and load the rest asynchronously.
Which WordPress plugin should I use?
Lighthouse points to plugins that inline critical assets or defer resources. Choose one and test it (my own advice).
Will fixing this improve rankings?
Neither Lighthouse nor Google promises it. Faster pages help users and Core Web Vitals.
Why did my site break after deferring scripts?
A script that other code depends on loaded too late. Exclude it from deferral.
What is flagged and the recommended fixes come from the Lighthouse page. The defer and async table, code examples, step-by-step plan, WordPress notes, troubleshooting table and checklists are my own.