When a browser reads a script or stylesheet in the head of a page, it usually stops to fetch and process it before showing anything. Each of those files delays the first paint, and with it the moment your main content appears. This guide covers how to eliminate render blocking resources: what the Lighthouse audit actually checks, the fix for each kind of file, and how to do it on WordPress without breaking the layout. The reference throughout is the Chrome for Developers documentation for the Lighthouse audit “Eliminate render-blocking resources”.
What Lighthouse flags as render-blocking
The audit is narrower than many people assume. It does not flag every script or every stylesheet; it applies two specific tests, and a file that fails either one is listed.
| Resource | Flagged when | Main fixes |
|---|---|---|
| Scripts | In the <head> with no defer and no async attribute | Inline critical scripts; add async or defer to the rest; remove unused code |
| Stylesheets | No disabled attribute, and no media attribute that rules them out for the device | Inline critical styles; load the rest asynchronously; split CSS by media query; minify |
Read the second row carefully. A stylesheet with a media attribute that matches the current device still blocks rendering. Only stylesheets the browser can tell it does not need right now, such as print styles, escape the audit.
How to eliminate render blocking resources in JavaScript
Scripts are usually the easier half. Start by sorting every script in the head into two groups: code the first paint genuinely depends on, and code that can wait. In most sites the second group is far larger than anyone expects, because analytics, chat widgets, consent tools and marketing tags tend to accumulate in the head.
Inline what is truly critical. A small script needed before the first paint can go directly in the HTML, which removes the extra request.
Defer or load asynchronously the rest. defer downloads the script in parallel and runs it after the HTML is parsed, in order. async downloads in parallel and runs as soon as the file arrives, in any order. Use defer for scripts that depend on each other or on the page, and async for independent ones such as analytics.
Remove unused code. The fastest script is the one you no longer load. Plugins and themes often ship code for features a page does not use. The coverage tool in Chrome DevTools shows how much of each file runs on a given page. For the search side of heavy client-side code, see our post on JavaScript SEO.
How to handle render-blocking CSS
CSS is harder, because the browser is right to wait for it. Painting a page before its styles arrive produces a flash of unstyled content, which is worse than a short delay. The goal is not to stop CSS from blocking but to make the blocking part as small as possible.
The documented approach is to “Inline critical styles required for the first paint inside a <style> block at the head of the HTML page”, then load the rest asynchronously. Critical styles are the rules needed for what appears above the fold: the header, the navigation, the headline and the first block of content.
The remaining stylesheet can be requested with a preload hint and applied once it has downloaded, so it no longer holds up the first paint:
Two smaller steps help as well. Split CSS by media query so that rules for print or for large screens sit in files the browser can skip on a phone, and minify what remains. Neither changes the architecture, but both shrink the blocking request.
Do not forget third-party stylesheets. A web font service usually loads through a stylesheet link in the head, and the audit treats it exactly like your own CSS. The same is true of stylesheets added by embeds, sliders and page builders. Check which of those the first screen really needs; often the answer is the font for the headline and nothing else, and the rest can be loaded later or dropped.
Eliminate render blocking resources on WordPress
On WordPress you rarely write this by hand. Caching and optimisation plugins offer options to defer JavaScript, delay scripts until interaction, generate critical CSS and load the remaining stylesheets asynchronously. They work, and for most sites they are the sensible route.
The received wisdom is to switch everything on and chase a perfect score. That is the wrong approach. Deferring a script that another inline script depends on breaks menus, sliders and forms. Generated critical CSS can miss rules for a template it was not built from, which shows up as a flash of unstyled content or a layout that jumps, the problem covered in our guide to Cumulative Layout Shift.
Change one setting at a time, clear the cache, and test the pages that matter: the home page, a typical article, a category page and anything with a form or checkout. Test logged out, on a phone-sized viewport, and click the interactive parts rather than just looking at the score. If a plugin offers exclusions, use them for the scripts that break.
What fixing it is worth
Render-blocking resources matter because they sit in front of everything else. When the main content is waiting behind a stylesheet or a synchronous script, no amount of image compression helps. That makes this audit one of the more reliable ways to improve Largest Contentful Paint, the Core Web Vital for loading.
Keep the ranking benefit in proportion. As our post on page speed and SEO sets out, Core Web Vitals are a small factor next to relevance. A faster first paint is worth having for the visitors who would otherwise leave before the page appears; it will not lift a page that does not answer its query.
One limitation to keep in mind: the Lighthouse audit is a lab test of a single load. It lists files that block rendering, but it cannot tell you how much each one costs your real visitors on their own devices and connections. Treat the list as a set of candidates, fix the largest ones first, and confirm the result in field data over the following weeks rather than in a single rerun.
Frequently asked questions
What is the difference between async and defer?
Both download the script without blocking the page. Defer runs scripts in order after the HTML is parsed; async runs each one as soon as it arrives, in any order.
Why does Lighthouse still flag my stylesheet?
Stylesheets block rendering unless they have a disabled attribute or a media attribute that does not match the device. A matching media query still blocks.
Can I eliminate render-blocking resources with a WordPress plugin?
Usually, yes. Caching and optimisation plugins can defer scripts and inline critical CSS, but test each change, because aggressive settings can break scripts and layouts.
Should all CSS be inlined?
No. Inline only the critical styles needed for the first paint and load the rest asynchronously. Inlining everything makes every page heavier.
The takeaway Defer what can wait, inline only what the first paint needs, and test every change on real templates. A cleaner audit is worth nothing if the menu stops working.
