Eliminate Render-Blocking Resources: How to Fix It
- August 22, 2025
- Performance, Resource Loading
Render-blocking resources are CSS and JavaScript files in your page <head> that the browser must download and process before it can paint anything on screen. They delay First Contentful Paint and Largest Contentful Paint, which hurts your Core Web Vitals and the experience visitors actually feel. Fix it by inlining the small amount of critical CSS, deferring the rest, adding defer or async to non-critical scripts, preloading key assets, removing unused code, and loading fonts without blocking the first paint.
What this means
Before a browser can paint a single pixel, it builds the DOM from your HTML and the CSSOM from your stylesheets. By default, both CSS and synchronous JavaScript sit on this "critical rendering path." A stylesheet in the <head> blocks rendering until it is downloaded and parsed. A plain <script> tag is worse: it blocks the parser entirely while it downloads and runs.
A render-blocking resource is therefore any CSS or JS file the browser must fetch and process before it can show content. The goal is not to strip out styling or scripts, but to make sure only the small slice of code needed for the first paint is treated as critical, and everything else loads out of the way.
Why it matters
Render-blocking resources directly delay First Contentful Paint (FCP) and, in turn, Largest Contentful Paint (LCP). LCP is a Core Web Vital, so a page weighed down by blocking CSS and JS is more likely to fail its CWV assessment, which can affect rankings and, more importantly, real user satisfaction.
The user impact is concrete: a slow first paint means people see nothing while the page loads, are more likely to bounce, and perceive your site as sluggish even on fast connections. Trimming the critical path is one of the highest-leverage performance wins available. For the LCP side of the equation, see our complete guide to Largest Contentful Paint.
How it gets flagged
Lighthouse and PageSpeed Insights raise this under the audit "Eliminate render-blocking resources," listing each blocking URL with an estimate of how many milliseconds you could save by deferring or inlining it. Lighthouse flags a resource when it is a stylesheet or a synchronous script in the document head that adds to the time before first paint.
Sitebulb, Screaming Frog, and similar crawlers surface the same issue, usually pulling from the same Lighthouse engine. The number you see is a lab estimate of potential savings, not a guaranteed real-world figure. Pair it with field data from the Chrome User Experience Report to confirm the impact, which we cover in field data vs lab data for Core Web Vitals.
How to fix it
1. Defer or async non-critical JavaScript. Add defer so a script downloads in parallel and runs after the HTML is parsed, in order. Use async for independent third-party scripts that do not depend on your DOM or each other.
2. Inline critical CSS and defer the rest. Put the styles needed for above-the-fold content into a <style> block in the head, then load the full stylesheet asynchronously with the preload pattern.
3. Preload key resources. Use <link rel="preload"> for assets the browser needs early, such as your main font or hero image, so they are fetched without sitting behind the CSSOM.
4. Remove unused CSS and JS. Audit with Chrome DevTools Coverage, then drop or split code that does not apply to the page, and minify what remains.
5. Load fonts well. Preload the WebFont and use font-display: swap so text renders immediately with a fallback instead of waiting on the font file.
<head>
<!-- Critical CSS inlined for first paint -->
<style>
body { margin: 0; font-family: system-ui, sans-serif; }
.hero { min-height: 60vh; background: #282d30; color: #fff; }
</style>
<!-- Preload the key font, then swap -->
<link rel="preload" href="/fonts/brand.woff2" as="font"
type="font/woff2" crossorigin>
<!-- Load the full stylesheet without blocking render -->
<link rel="preload" href="/css/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
<!-- Defer non-critical JS so it never blocks parsing -->
<script src="/js/app.js" defer></script>
</head>For JavaScript-heavy sites, confirm the deferred approach does not delay content that needs to be crawled. Our JavaScript SEO and rendering guide covers balancing performance with discoverability.
False positives
Not every flagged resource is worth chasing. A file reported as blocking for a few milliseconds rarely changes the experience. If a stylesheet truly is critical to the first paint it should block, that is correct behavior, and forcing it async can cause a flash of unstyled content that is worse than the wait. Scripts already marked defer or async can still appear in older reports, so verify in DevTools before acting. Treat the audit as a prioritized list, not a mandate to defer everything.
FAQ
Both download the script without blocking the parser. defer runs scripts after HTML parsing, in document order, which suits your own app code. async runs each script as soon as it arrives, in no guaranteed order, which suits independent third-party tags.
No. Tools and build plugins can extract above-the-fold CSS automatically. Many WordPress performance plugins generate and inline critical CSS for you, then load the full stylesheet asynchronously.
It helps FCP and LCP, but CWV also depends on server response time, image sizing, layout shifts, and third parties. Use the audit as one input and confirm progress with real field data.
Usually, but test it. Scripts that build above-the-fold content or that other scripts depend on may break if deferred carelessly. Defer in stages and check each page renders and behaves correctly.
An advanced SEO audit maps your full critical rendering path, flags the resources that actually cost you LCP, and gives you a prioritized fix list.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
