Fix eliminate render-blocking resources Lighthouse warning
Get rid of render-blocking resources and improve the Core Web Vitals
'Eliminate render-blocking resources' in short
When a browser encounters render-blocking CSS or JavaScript in the <head>, it stops everything. No pixels get painted until those resources finish downloading and executing. That is what the 'Eliminate render-blocking resources' warning in Lighthouse is telling you: something in your <head> is delaying the first paint.
Fix this Lighthouse warning by removing or deferring these render-blocking resources. According to the 2025 Web Almanac, only 15% of mobile pages pass this audit. That is 85% of the web with unnecessary rendering delays.
What is the 'Eliminate render-blocking resources' Lighthouse warning?
Last reviewed by Arjen Karel on March 2026
What causes the Eliminate render-blocking resources warning in Lighthouse? Lighthouse flags pages that have either:
- A script tag in the head that is not deferred.
Scripts in the head of the page are render-blocking by default if they do not have the defer or async attribute. - A linked stylesheet that matches the device media.
A <link rel="stylesheet"> will block the rendering of the page if it is not disabled and matches the media of the browser. For example <link rel="stylesheet" media="print"> will not block the rendering on screen devices.
Too many render-blocking resources will most likely affect First Contentful Paint (FCP) and Largest Contentful Paint (LCP) directly. Vodafone reduced render-blocking JavaScript and saw a 31% improvement in LCP, which translated to an 8% increase in sales.
According to the Web Performance Calendar, 67.7% of websites load at least one render-blocking third party. Google Fonts alone is responsible for render-blocking requests on over 5.8 million sites.
What causes 'render-blocking resources'?
Render-blocking resources are always stylesheets and JavaScripts in the head of the page. This means they can only be added by your CMS, by your web developer, or by a plugin. When trying to find the origin of a render-blocking resource try looking in these places:
- The template. The template of your website is the first place to look. Find the place where the <head> code is located and look for hardcoded styles and scripts.
- The CMS. Sometimes the CMS itself requires some scripts (for example jQuery) to work properly.
- Plugins. Plugins are notorious for injecting styles and scripts into the page. Even when a plugin is only used on one page, it often loads its resources on every page.
The 2024 Web Almanac's JavaScript chapter (the most recent edition with script-level data) found that while 87% of pages use async on at least one script, only 49% of individual script tags actually have it. And just 13% of scripts use defer. Most scripts on the web are still loaded without either attribute, which means they block rendering.
How to fix 'Eliminate render-blocking resources'
To fix render-blocking resources you need to make sure they no longer block rendering. The best fix is to remove the resource entirely. Old, unused scripts and stylesheets that are still in the <head> are more common than you think. If you cannot remove them, defer them.
Deferring JavaScript
JavaScript can be deferred by adding the defer or async attribute to the script tag.
<!-- deferred: downloads in parallel, executes after HTML parsing, in order --> <script defer src="script.js"></script> <!-- async: downloads in parallel, executes immediately when ready (any order) --> <script async src="script.js"></script>
For most scripts, defer is the safer choice because it preserves execution order. Use async for scripts that are completely independent, like analytics. If you use ES modules (<script type="module">), you get defer behavior automatically. Module scripts never block rendering.
For a complete guide on all the ways to control JavaScript timing, see 16 methods to defer JavaScript. If you want to understand how async and defer affect the Core Web Vitals differently, we have a dedicated article on that too.
Deferring stylesheets
Deferring stylesheets is trickier than deferring scripts. When a stylesheet is deferred the page renders without those styles first, then the browser applies them once loaded. This causes flickering and layout shifts. That is why you need to pair deferred stylesheets with inline critical CSS.
Step 1: Inline your critical CSS. Critical CSS is the minimal set of styles needed to render the visible part of the page. Inline it directly in a <style> tag in the <head>. This gives the browser everything it needs to paint the above-the-fold content without waiting for an external file. Extracting critical CSS by hand is tedious. You can use our Critical CSS Generator to automate this.
<style>/* critical CSS here */</style>
Step 2: Load the rest with low priority. For the non-critical stylesheet, add fetchpriority="low" to tell the browser this resource should not compete with critical content:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
You might see older articles recommend a media="print" hack that swaps to media="all" on load. I do not recommend this. It abuses the media attribute for something it was not designed for, it depends on a fragile onload handler, and if that handler fails your styles never apply. Using fetchpriority="low" is the correct, semantic approach: it tells the browser exactly what you mean without tricks.
For stylesheets you do not need on the current page at all (for example styles only used on a specific page type), the cleanest solution is to remove the unused CSS from that page entirely.
Reduce the impact of render-blocking resources
Sometimes you cannot eliminate render-blocking resources. You might not have access to the template or your CMS might require certain scripts. There are a few ways to reduce the impact:
- Minify and compress your styles and scripts.
Smaller resources have less of an impact on loading performance than larger resources. Make sure gzip or brotli compression is enabled on your server. - Avoid chaining critical requests.
If a render-blocking stylesheet loads another stylesheet via@import, you have created a request chain. The second file cannot start downloading until the first is fully loaded and parsed. Use separate<link>tags instead so both download in parallel. - Unload resources per page.
When a resource cannot be removed from one page that does not mean it is required on all pages. WordPress plugins tend to add scripts and styles to all pages, even when the plugin is only active on a few. - Prioritize what matters.
Use resource prioritization to make sure critical resources load first and non-critical resources do not compete for bandwidth.
In CoreDash monitoring data, sites that eliminated all render-blocking resources saw their FCP improve by [CD:placeholder]ms on average.
Search Console flagged your site?
When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.
Request Urgent Audit
