Eliminate Render-Blocking Resources

When PageSpeed Insights or Lighthouse tells you to eliminate render-blocking resources, it has found CSS or JavaScript that the browser must download and process before it can paint anything on screen. Until those files are handled, the visitor sees a blank page. Removing them from the critical path is one of the most effective ways to improve how fast a page feels.

From PerfDelta's measurements: Lighthouse reports this finding on 91% of 5,509 measured home pages. The median estimated saving is 5232 ms. More in the data section below.

What are render-blocking resources?

The critical rendering path is the sequence of steps a browser takes to turn HTML, CSS and JavaScript into pixels. Two things block it by default. Every <link rel="stylesheet"> is render-blocking, because the browser must build the full CSSOM before it paints, otherwise the page would flash unstyled content. And a synchronous <script> in the <head> is parser-blocking: the browser stops building the page, downloads the script, and executes it before it continues. Lighthouse lists each blocking file along with the estimated time you would save by deferring it.

Why it matters for performance and Core Web Vitals

Render-blocking resources delay First Contentful Paint and often Largest Contentful Paint, the two metrics a visitor experiences as the page finally appearing. It is one of the most common reasons an otherwise fast site still feels slow, and one of the most common LCP bottlenecks. Because Core Web Vitals are a Google ranking signal, clearing the critical path improves both the real user experience and search visibility.

How to eliminate render-blocking resources

1. Identify the blocking files

PageSpeed Insights names each render-blocking resource directly. In Chrome DevTools, the Performance panel flags blocking requests, and the Coverage tab shows how much of each blocking file is actually used, which tells you whether the fix is deferral, trimming, or both.

2. Defer or async your JavaScript

A script in the <head> without an attribute blocks parsing. Two attributes remove it from the critical path, and the difference matters:

<!-- Downloads in parallel, runs AFTER parsing, in order. Best default. -->
<script defer src="/app.js"></script>

<!-- Downloads in parallel, runs AS SOON AS ready, no order guarantee. -->
<script async src="/analytics.js"></script>

Use defer for most scripts, especially anything that depends on the DOM or on load order. Use async for independent scripts such as analytics, where execution order does not matter.

3. Inline critical CSS and defer the rest

Rather than loading one large stylesheet up front, inline the small amount of CSS needed for the above-the-fold content in the <head>, then load the full stylesheet without blocking:

<link rel="preload" href="/styles.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

Do this carefully. If the deferred stylesheet arrives late and the inline critical CSS is incomplete, users briefly see a flash of unstyled content, so keep the critical CSS accurate and small.

4. Reduce what still has to load

The less CSS and JavaScript sits on the critical path, the less there is to block it. Trimming unused CSS and unused JavaScript directly shrinks the render-blocking payload, so the two audits reinforce this one. Split large bundles so only what the page needs loads first.

5. Preconnect and preload key resources

For resources that must load early, such as a web font or the hero stylesheet, shorten the path by warming the connection and hinting the fetch:

<link rel="preconnect" href="https://fonts.example.com">
<link rel="preload" href="/hero.css" as="style">

Web fonts are a frequent hidden render-blocker. Add font-display: swap so text renders immediately in a fallback font while the web font downloads, and preload the one or two font files used above the fold so they arrive as early as possible.

6. Handle third-party render-blockers

Third-party tags added in the <head> often block rendering too. Defer them, self-host where the licence allows, or remove tags that no longer earn their place. You control when they load even when you cannot change their code.

7. Keep the critical path clear

New scripts and stylesheets creep back into the head over time. A performance budget enforced in your build pipeline, checked with Lighthouse CI, fails a change that reintroduces a render-blocking resource before it reaches production.

How to verify the fix

Re-run PageSpeed Insights or Lighthouse and confirm the render-blocking list has shrunk and First Contentful Paint has improved. Load the page on a throttled connection and watch for any flash of unstyled content, which signals the critical CSS needs adjusting. Lab results change immediately, while field data in the Chrome UX Report reflects a trailing 28-day window. Test several templates, since the blocking resources differ between a landing page and an article.

Render-blocking resources by platform

WordPress

Every active plugin can enqueue a stylesheet and a script in the head, and most do so on every page. Caching plugins offer options to defer JavaScript and inline critical CSS; an asset manager restricts each plugin to the pages where it is used. See the WordPress guide.

Shopify

Render-blocking resources are the most common Lighthouse finding on Shopify stores in our data, usually theme CSS and app scripts in the head. Current theme-store themes defer their JavaScript; apps are the part to audit. See the Shopify guide.

Next.js

Next.js splits and defers its own JavaScript, so blocking resources there are usually a global CSS import that grows with every component, a third-party script loaded with the wrong next/script strategy, or a font stylesheet from an external service instead of next/font. See the Next.js guide.

Frequently asked questions

What are render-blocking resources?

They are CSS and JavaScript files the browser must download and process before it can paint the page. Stylesheets block painting so the page does not flash unstyled, and synchronous scripts block HTML parsing until they run.

What is the difference between async and defer?

Both download the script in parallel without blocking parsing. defer runs scripts after the HTML is parsed and preserves their order, which suits most cases. async runs each script as soon as it is ready with no order guarantee, which suits independent scripts like analytics.

How do I eliminate render-blocking CSS?

Inline the critical above-the-fold CSS in the head and load the rest of the stylesheet asynchronously with a preload swap. Reducing unused CSS first makes the critical stylesheet smaller and the fix easier.

Is inlining CSS bad for performance?

Inlining a small amount of critical CSS is good, because it lets the browser paint without a network request. Inlining the entire stylesheet is not, since it bloats the HTML and cannot be cached separately. Keep inline CSS limited to the above-the-fold content.

Does eliminating render-blocking resources improve Core Web Vitals and SEO?

Yes. Clearing the critical path improves First Contentful Paint and often Largest Contentful Paint. Because Core Web Vitals are a ranking signal, the improvement benefits both users and search visibility.

How do I eliminate render-blocking resources in WordPress?

A caching plugin such as WP Rocket can defer JavaScript and generate critical CSS without code. Enable those options, then test key templates, because aggressive deferral can break interactive elements or cause a brief unstyled flash.