Render-Blocking Resources: What They Are and How to Fix Them

Short answer: render-blocking resources are files, mainly CSS in the head and synchronous JavaScript, that the browser must download and process before it can paint anything on screen. They delay First Contentful Paint and often Largest Contentful Paint. Fix them by adding defer to scripts that do not need to run first, removing unused CSS and JavaScript, inlining a small amount of critical CSS, and loading non-essential styles and third-party code later.

How rendering gets blocked

When a browser receives HTML, it reads it from top to bottom and builds the page. Two kinds of resources make it wait:

• Stylesheets. The browser will not paint content until it has downloaded and parsed the CSS in the head, because painting without styles would show an unstyled page and then redraw it. All <link rel="stylesheet"> elements that apply to the current screen are render-blocking by default.
• Synchronous scripts. A plain <script src="..."> in the head stops HTML parsing until the script is downloaded and executed, because the script might change the page. Everything after it waits.

Each blocking file costs at least a network round trip, and more if it is large, served from another domain or itself imports further files. On a mobile connection, a handful of blocking files can add a second or more before anything appears. The mechanics are explained well on web.dev’s critical rendering path guide.

Why it matters for SEO and users

A blank screen is the worst possible start to a visit. Render-blocking resources push back:

• First Contentful Paint, when the first text or image appears;
• Largest Contentful Paint, a Core Web Vital, because the main content cannot be painted before the blocking files are processed;
• perceived speed, which drives whether visitors wait or go back to the results.

Search engines render pages with a browser engine, so the same files also have to be fetched during rendering. Heavy, slow resources make rendering more expensive, which is one more reason to keep them lean.

How to find render-blocking resources

1. PageSpeed Insights lists “Eliminate render-blocking resources” with each file and its estimated saving.
2. Chrome DevTools Performance panel shows the network waterfall and when the first paint happens relative to each file.
3. Coverage panel in DevTools shows how much of each CSS and JavaScript file is actually used on the page. Often the answer is a small fraction.
4. View source and read the head: every stylesheet link and every script without defer, async or type="module" is a candidate.

Check each main template, since plugins and themes often add different files to different pages.

Fixing render-blocking JavaScript

Scripts have three loading modes, and choosing the right one solves most problems:

Practical steps:

• Add defer to theme and plugin scripts. Test carefully, because inline scripts that depend on a library, such as jQuery, can break if the library is deferred and the inline code is not.
• Move scripts out of the head when defer is not possible.
• Remove scripts that are not needed on a page. A gallery script on a text-only page, or a form library on pages without forms, is pure cost.
• Load third-party widgets later, after the page is usable or when the visitor interacts.
• Avoid anti-flicker snippets from testing tools that hide the entire page until their script has loaded, unless the test really needs it.

Fixing render-blocking CSS

CSS cannot simply be deferred wholesale, because without it the page would flash unstyled. The goal is to make the blocking part small:

• Remove unused CSS. Page builders, component libraries and themes often ship styles for every possible feature. Many optimisation tools can generate per-page CSS containing only the rules in use.
• Inline critical CSS. Put the small set of styles needed for the first screen directly into the head, and load the full stylesheet without blocking. This gets the first paint out quickly while the rest arrives.
• Split by media. Styles only for print or wide screens can use a media attribute so they do not block rendering on phones.
• Avoid @import inside CSS files, which creates a chain of sequential downloads.
• Combine small files carefully. With HTTP/2 many small files are fine, but dozens of separate plugin stylesheets still add overhead.

Fonts and third-party origins

Fonts are not render-blocking in the same way, but they often delay text:

• Use font-display: swap or optional so text appears in a fallback font immediately.
• Preload the one or two font files needed for the first screen.
• Host fonts on your own domain when possible, avoiding an extra connection to another origin.
• Load only the weights and character sets you use.

Every additional domain in the head, whether for fonts, a CSS framework from a CDN or a tag manager, needs its own DNS lookup and connection. Where a third-party origin is essential early, a preconnect hint can shave off part of that time.

Render-blocking resources on WordPress

WordPress sites commonly accumulate blocking files because each plugin enqueues its own CSS and JavaScript on every page. A sensible approach:

1. List the stylesheets and scripts in the head of a typical page and note which plugin or theme adds each one.
2. Remove plugins you do not need.
3. Use a performance plugin or asset manager to disable plugin assets on pages where they are not used.
4. Enable script deferral and test key functions: menus, forms, sliders, cart and checkout.
5. Consider generating critical CSS, again testing templates visually afterwards.
6. Check that the theme does not load large icon fonts or libraries for minor features.

Always test on a staging copy first. Aggressive optimisation settings are a common cause of broken menus and checkout pages.

How to confirm the change actually helped

Optimising render-blocking resources is easy to overdo and easy to misjudge, so measure before and after in a consistent way:

1. Record a baseline for each main template on mobile: First Contentful Paint and LCP from a lab run, plus the number and total size of blocking files in the head.
2. Change one thing at a time, for example deferring scripts first and trimming CSS later, so you know which change caused which effect.
3. Compare filmstrips, not only numbers. DevTools and PageSpeed Insights show screenshots over time; you want the first meaningful content to appear earlier and the page to look complete without flashes or jumps.
4. Test functionality: navigation on mobile, forms, sliders, search, cart and checkout, cookie consent and any interactive widgets.
5. Watch field data in Search Console over the following four weeks, since it is a rolling 28-day window.

If a change improves the lab score but the filmstrip shows content appearing later or shifting more, undo it. The purpose is a faster experience, not a better number.

Mistakes to avoid

• Deferring scripts that page content depends on, so content appears late or not at all. Check the rendered page, not just the score.
• Loading all CSS asynchronously without critical CSS, which causes a flash of unstyled content and layout shifts.
• Delaying all JavaScript until user interaction on pages where the main content is built by JavaScript; crawlers and visitors may see an empty page.
• Chasing a perfect lab score instead of real-user LCP improvements.

How Site SEO AI Audit helps

The speed and Core Web Vitals area of the audit brings in Google PageSpeed data, including LCP and CLS, and measures server response time, compression and page weight on every crawled page. Templates that are consistently heavy stand out, which usually points to the same blocking scripts and stylesheets loaded site-wide. The AI visibility area also flags content that needs JavaScript to appear, a closely related problem. See plan details.

Related reading

• How to fix a slow Largest Contentful Paint (LCP)
• Page weight and compression: how to make pages lighter
• Interaction to Next Paint (INP): how to find and fix delays

The bottom line

Render-blocking CSS and JavaScript keep the screen blank until they are processed. Defer scripts that do not need to run first, remove unused code, keep the critical CSS small and inline, load fonts and third parties sensibly, and test that content and functionality still work after every change.

FAQ

What is a render-blocking resource?

It is a file the browser must download and process before it can show content, mainly stylesheets in the head and scripts without defer or async. Until they are handled, the visitor sees a blank or incomplete screen.

Should I use defer or async?

Use defer for most site scripts, because it keeps execution order and runs after the HTML is parsed. Use async for independent scripts, such as analytics, that do not depend on other code.

Can I make all CSS non-blocking?

Not safely. Without any CSS the page flashes unstyled and may shift. The usual solution is to inline a small critical CSS block for the first screen and load the rest without blocking.

Do render-blocking resources affect SEO?

Indirectly. They slow First Contentful Paint and Largest Contentful Paint, which affect user experience and Core Web Vitals, a page experience signal. They also add work when search engines render pages.

Why did my site break after deferring JavaScript?

Usually an inline script expects a library, such as jQuery, that is now loaded later. Exclude that library from deferral or defer the dependent inline code as well, and test menus, forms and checkout.