Files, typically CSS and JavaScript, that the browser must download, parse, and execute before it can paint the page.
Web developers or SEO specialists reading about web performance optimization and Core Web Vitals.
01What it is and how it works
When a browser loads a page, it builds a DOM from HTML and a CSSOM from stylesheets. If a ` tag is in the without defer or async, the browser pauses HTML parsing to fetch and run it. Similarly, a ` blocks rendering because the browser needs the CSSOM to paint. The more render-blocking resources you have, the longer the user stares at a blank screen. Google's Lighthouse flags these resources and measures their impact on First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
Render-blocking resources are scripts and stylesheets that stop the browser from showing content until they finish loading. Removing or deferring them makes pages appear faster.
02What to do about it
You can reduce or eliminate render-blocking resources with a few practical steps. Inline critical CSS—the styles needed for above-the-fold content—directly in the `. Load non-critical CSS using media attributes or preload with onload. For JavaScript, add defer or async to tags, or move scripts to the end of the `. Split your JavaScript bundles so only essential code loads first. Use tools like Lighthouse or PageSpeed Insights to identify which resources block rendering, then apply these fixes. For WordPress, consider a performance plugin that handles critical CSS and script deferral automatically.
03How it is measured
Lighthouse and PageSpeed Insights report a specific audit called "Eliminate render-blocking resources." It lists each blocking URL and the estimated time saved by deferring or inlining it. The metric is tied to FCP and LCP in Core Web Vitals. You can also use the Chrome DevTools Performance panel: record a page load, look at the "Main" track, and see where the browser stalls on a stylesheet or script. The Network tab shows which resources are requested before the first paint event. Google Search Console's Core Web Vitals report will flag pages with poor LCP, often caused by render-blocking scripts.
04Common mistakes
- Deferring all JavaScript, including scripts that must run before the page is interactive—this delays time-to-interactive.
- Inlining huge CSS files, which bloats the HTML and can hurt performance on slow connections.
- Using
asyncfor scripts that depend on other scripts, causing race conditions and broken functionality. - Forgetting to remove unused CSS or JavaScript—dead code still blocks rendering.
- Preloading every resource instead of only critical ones, which wastes bandwidth and delays real critical assets.
05Limits and confusions
Not all resources are render-blocking. Images, videos, and fonts loaded via ` or @font-face do not block rendering (though they affect LCP). Scripts with async or defer` do not block parsing. Also, render-blocking is not the same as "render-delaying"—a large image can delay LCP without blocking the first paint. And a resource might be flagged as render-blocking but have minimal impact if it's small or cached. The audit's time-saved estimate is a best-case scenario, not a guarantee. Finally, render-blocking resources are a performance issue, not a direct ranking factor—they hurt rankings indirectly through Core Web Vitals.
06Worked example
Suppose your homepage has a<link rel="stylesheet" href="styles.css">and a<script src="app.js"></script>in the<head>. Lighthouse says styles.css saves 0.8s and app.js saves 0.5s if deferred. You inline the critical CSS (the header and hero styles) into a<style>tag, then load the rest of styles.css withmedia="print" onload="this.media='all'". You adddeferto app.js. After the change, FCP drops from 2.1s to 1.3s, and your LCP improves from 3.4s to 2.2s. The page now passes the Core Web Vitals threshold for mobile.
Frequently asked questions
What's the difference between render-blocking and non-render-blocking resources?
Render-blocking resources must be fetched and parsed before the browser can render, while non-render-blocking resources like images or async scripts don't delay the initial paint. The key difference is whether the browser pauses rendering while the resource loads. In practice, CSS is often render-blocking, while JavaScript can be made non-render-blocking with async or defer.
Should I eliminate all render-blocking resources?
No, not all of them. You should eliminate or defer resources that aren't critical for the initial content, like non-essential JavaScript, but some CSS is necessary to style the page. The goal is to inline critical CSS and defer the rest, balancing speed with functionality.
How do I inline render-blocking JavaScript?
You don't inline JavaScript; instead, you load it with the defer attribute or use async where appropriate. For CSS, you can inline critical styles directly in the HTML and defer the rest using media="print" or preload techniques. Tools like Lighthouse provide specific recommendations for each blocking URL.
Does fixing render-blocking resources improve my search rankings?
Yes, indirectly. Render-blocking resources delay first contentful paint, which is a Core Web Vital that Google uses as a ranking factor. Reducing them improves page speed and can boost your rankings, especially on mobile. However, it's one of many factors, so the impact varies.
What happens if I don't fix render-blocking resources?
Your page will have a slower first paint, leading to higher bounce rates and worse user experience. Over time, this can hurt your search rankings and make your site look poor in performance audits. You'll also see low Lighthouse scores, which can be a concern for clients or stakeholders.
How long does it take to see improvements after fixing render-blocking resources?
You'll see immediate improvements in your Lighthouse and PageSpeed Insights scores once you deploy the changes. For search rankings, it depends on how often Google crawls your site, but you might notice changes within a few weeks. Monitor your Core Web Vitals in Google Search Console to track progress.
Asked out loud
spoken, not typedThe same term in the words somebody uses speaking to an assistant rather than typing into a box — written from the situation, which is why each one carries the situation it came from.
It's likely render-blocking resources. These are files like CSS and JavaScript that the browser must download before it can paint the page. You can fix it by inlining critical CSS and deferring non-essential scripts.
That's the render-blocking resources audit. It lists specific URLs that are slowing down your first paint. You can fix it by deferring those scripts or inlining the critical CSS, and the report even shows you how much time you'll save.
Check for render-blocking resources first. They're the most common cause of slow first paint and are easy to fix. Run a PageSpeed test and look at the "Eliminate render-blocking resources" audit to see exactly what's holding the page back.