Render-blocking resources are files, usually CSS stylesheets and JavaScript, that a browser must download and process before it can show anything on the page. For example, if your homepage loads a large stylesheet and two scripts in the head of the page, visitors may stare at a blank screen until all three arrive, even if the text and images are ready.
For a business, render-blocking resources are a common reason a site feels slow to load, especially on mobile connections. They often come from themes, plugins, fonts and third-party tools added over time. Reducing them helps visitors see your content sooner and supports better page experience metrics.
What are render-blocking resources?
To show a page, a browser follows the critical rendering path, which web.dev defines as the steps involved until the web page starts rendering in the browser. Some files along that path pause rendering until they're ready. Those are render-blocking resources.
CSS is render-blocking by default. web.dev explains that when the browser encounters CSS, it avoids rendering more content until it has finished downloading and processing that CSS. This is deliberate: without styles, the page would briefly look broken and then change considerably once the CSS loads.
Scripts behave a little differently. By default, JavaScript is parser-blocking, which means the browser stops reading the HTML while it downloads and runs the script, unless the script is marked async or defer. Chrome's Lighthouse documentation lists the resources it treats as render-blocking:
- Scripts in the head of the document that don't have a defer or async attribute
- Stylesheets that aren't disabled and whose media attribute doesn't specifically exclude the visitor's device. A media value of "all" still counts as blocking
Why render-blocking resources matter
They delay what visitors see. Chrome's documentation for its render-blocking requests insight says these requests block the page's initial render, which may delay Largest Contentful Paint (LCP). LCP is one of the Core Web Vitals, so blocking files can affect how Google measures your page experience.
They add up quietly. Each plugin, font file, chat widget or analytics tool can add another file to the head of the page. A site can go from fast to slow without any single change that looks serious.
Mobile visitors feel it most. On slower connections, every blocking file takes longer to arrive, so the blank screen lasts longer.
Crawlers need your content to render. Search engines and some AI crawlers process pages to read their content. Heavy reliance on blocking scripts makes pages slower and more fragile to render, which is part of why JavaScript SEO recommends keeping critical content easy to reach.
How render-blocking resources work
Render-blocking CSS
The browser needs CSS to know how the page should look, so it waits for stylesheets before painting. web.dev notes that if a stylesheet's media attribute doesn't match the current conditions, such as a print stylesheet on a screen, it isn't render-blocking. A newer blocking attribute also lets developers explicitly mark a link, script or style element as render-blocking when they need to.
Parser-blocking JavaScript
A regular script tag stops the HTML parser until the script downloads and runs, because the script might change the page. Adding async lets the script download in the background and run when ready. Adding defer lets it download in the background and run after the HTML is parsed. Scripts loaded as modules are deferred by default.
How tools report them
Lighthouse long had an audit called "Eliminate render-blocking resources." Chrome's documentation says that as of Lighthouse 13, this audit has moved into the Render-blocking requests insight, part of a set of performance insights that Chrome now shares between Lighthouse and the DevTools Performance panel. To pass the insight, you remove all requests that block the page's first paint.
How to reduce render-blocking resources
- Run a test. Use PageSpeed Insights, Lighthouse or the Chrome DevTools Performance panel to list the requests that block rendering.
- Find what's actually used. Chrome's documentation recommends the Coverage tab in DevTools, which shows which CSS and JavaScript the page uses and which it doesn't.
- Defer non-critical scripts. Add defer or async to scripts that aren't needed for the first view, such as analytics, chat widgets and sliders further down the page.
- Trim and remove. Delete unused plugins, styles and scripts. Chrome's guidance is to reduce CSS and scripts to only what the first paint needs.
- Use media attributes. Split styles that only apply in certain conditions, such as print, into separate files with a matching media attribute.
- Inline small critical code carefully. Chrome suggests inlining requests that are critical for first paint but small. It also calls inlining CSS an advanced technique and says most sites can reach the recommended targets without it.
- Use your platform's tools. Chrome notes that platforms like WordPress, Drupal and Joomla have plugins or modules for inlining critical assets and deferring less important ones.
Common mistakes and misconceptions
- "All render-blocking files are bad." Some blocking is needed. The CSS that styles the top of the page should load first, or the page will look broken. The goal is to block only on what the first view needs.
- "Deferring everything is the fix." Deferring scripts that build the main content can make that content appear later, not sooner. Test after each change.
- "Async and defer do the same thing." Async scripts run as soon as they download, in any order. Deferred scripts run in order after the HTML is parsed.
- "A plugin will solve it automatically." Optimization plugins help, but aggressive settings can break layouts or features. Check key pages on real devices.
- "The Lighthouse audit is gone, so it doesn't matter." The check now lives in the Render-blocking requests insight. The problem is the same.
Render-blocking vs. parser-blocking
A render-blocking resource stops the browser from painting the page until it's ready. A parser-blocking resource stops the browser from reading the rest of the HTML until it's ready. CSS is render-blocking by default but doesn't stop the parser. A regular script in the head blocks the parser, and with it the render. Knowing the difference helps you pick the right fix: media attributes and trimming for CSS, async and defer for scripts.
How Butter approaches render-blocking resources
At Butter, render-blocking resources come up when we review page speed and how well pages render for search engines. We run tests on the pages that matter most for leads and sales, identify which files block the first view and recommend what to defer, trim or remove.
We also look at the server side, since a slow Time to First Byte can hide behind a blocking-resource problem. Many fixes are made by a client's developer or through their CMS, so we share specific, prioritized recommendations and recheck after changes go live.
Frequently asked questions
What counts as a render-blocking resource?
Mainly CSS stylesheets and scripts in the head of the page. Lighthouse flags head scripts without async or defer, and stylesheets whose media attribute doesn't exclude the visitor's device.
Do render-blocking resources affect SEO?
They can, indirectly. Chrome's documentation says they may delay Largest Contentful Paint, which is a Core Web Vital that Google uses to measure page experience.
What replaced the Lighthouse "Eliminate render-blocking resources" audit?
As of Lighthouse 13, the audit moved into the Render-blocking requests insight. It checks for the same problem: requests that block the page's first paint.
Should I inline all my CSS?
No. Chrome suggests inlining only small, critical code for the first view and calls inlining CSS an advanced technique. Most sites can hit recommended targets by deferring, trimming and removing unused files instead.