How to Eliminate Render-Blocking Resources on Your Website

Short answer: Render-blocking resources are CSS files and synchronous JavaScript files in the page’s head that the browser must download and process before it can show anything. To eliminate them, add defer to scripts that do not need to run before the first paint, remove unused CSS and JavaScript, load non-critical stylesheets separately, and inline the small amount of CSS needed for the top of the page. Test after each change, because deferring the wrong script can break menus, sliders or forms.

“Eliminate render-blocking resources” is one of the most frequent recommendations in PageSpeed Insights and Lighthouse, and also one of the most confusing. The recommendation does not mean you should delete your stylesheets. It means the browser is waiting for files before it paints the first pixel, and some of that waiting is unnecessary. On a fast desktop connection the delay may be barely visible; on a phone over a mobile network, it can add seconds of blank screen.

Why browsers block rendering

To draw a page correctly, the browser needs to know how things look. That is why CSS is render-blocking by default: if the browser painted before the styles arrived, visitors would see a flash of unstyled content followed by a jump into the final layout. Browsers deliberately wait for stylesheets referenced in the head.

JavaScript blocks for a different reason. A classic <script src="..."> without attributes might change the page, for example with document.write, so the browser stops parsing the HTML, downloads the script, runs it and only then continues. Every such script in the head delays everything below it.

The browser can only start painting once the HTML up to the visible content has been parsed and all blocking CSS has been processed. Each blocking file adds at least one network round trip, plus download and processing time.

How to find render-blocking resources

1. PageSpeed Insights lists render-blocking requests with their size and the estimated time saving if they were removed from the critical path.
2. Chrome DevTools Network panel: sort by the waterfall and look at what loads before the first paint marker. Files in the head that start early and finish before the first paint are candidates.
3. The Coverage tab in DevTools shows how much of each CSS and JavaScript file is actually used on the page. Large files with mostly unused code are prime targets.
4. View the page source and look at the head: every <link rel="stylesheet"> and every <script src> without defer, async or type="module" blocks rendering.

Fixing render-blocking JavaScript

Scripts are usually the easiest win. There are three main options:

Practical steps:

• Add defer to theme and plugin scripts that handle menus, sliders, forms and other interactive parts. They usually do not need to run before the first paint.
• Keep the order of dependent scripts. If a script depends on a library such as jQuery, both must be deferred, or the dependency must load first.
• Move scripts from the head to the end of the body if you cannot add attributes; this avoids blocking the visible content.
• Remove scripts that are not used on the page at all, for example a gallery script loaded on every page but needed on one.
• Watch out for inline scripts that call functions from a deferred file; they will fail if they run before it loads.

Fixing render-blocking CSS

CSS is harder, because you cannot simply defer all of it without the page appearing unstyled. The goal is to make the CSS needed for the first screen as small as possible and load the rest without blocking.

• Remove unused CSS. Themes and page builders often load one large stylesheet with styles for every possible component. Plugins may add stylesheets on every page even when their feature is only used on one. Disable those per page where your tools allow it.
• Split by page type. Load shop styles only on shop pages, form styles only where there is a form.
• Use media attributes. A stylesheet with media="print" does not block rendering on screen. Stylesheets for specific screen sizes can use matching media queries.
• Inline critical CSS. Put the small set of rules needed for the above-the-fold content directly in a <style> block in the head, and load the full stylesheet without blocking. This is effective but requires maintenance; many optimisation plugins automate it.
• Avoid @import in CSS. It creates chains where one stylesheet must download before the browser discovers the next.

Fonts and third-party stylesheets

Web fonts loaded from an external stylesheet add two steps: first the stylesheet from the font provider, then the font files it references. Both are on the critical path.

• Host fonts on your own domain where licensing allows, to avoid the extra connection.
• Use font-display: swap or optional so text appears in a fallback font immediately.
• Preconnect to font or CDN domains you must use, so the connection is ready earlier.
• Review third-party CSS from widgets and embeds; some load large stylesheets in the head that are only used far down the page.

Using optimisation plugins safely

On WordPress and similar platforms, plugins can defer scripts, combine files, remove unused CSS and generate critical CSS automatically. They are useful, but they are also the most common cause of broken layouts after a “speed optimisation”.

1. Work on a staging copy of the site, or at least at a quiet time.
2. Enable one feature at a time: first script deferral, then CSS optimisation, then critical CSS.
3. After each step, test menus on mobile, sliders, forms, cookie banners, cart and checkout.
4. Use the plugin’s exclusion lists for scripts that must not be deferred.
5. Clear all caches (plugin, server and CDN) before testing.
6. Do not run two optimisation plugins that both rewrite CSS and JavaScript.

A worked example

Consider a typical business site whose head contains a theme stylesheet, a page-builder stylesheet, a slider stylesheet, a font stylesheet from an external provider, jQuery, a slider script and a cookie consent script, all loaded without attributes. On a phone, the browser has to fetch seven files before painting. A sensible clean-up would be: remove the slider stylesheet and script from every page except the home page where the slider lives; add defer to jQuery and the slider script together so their order is kept; host the font locally with font-display: swap; keep the consent script early if the consent tool requires it; and leave the theme and builder stylesheets blocking for now. The critical path shrinks from seven files to three, without any risky critical-CSS generation. Only if the first paint is still slow would the next step be to trim or split the builder CSS.

What not to worry about

Not every render-blocking file is worth removing. A small, well-cached stylesheet from your own domain costs little, especially on repeat visits. Payment provider scripts on checkout pages may need to load early for security reasons. Consent management scripts sometimes must run before other scripts to respect visitors’ choices. Focus on the files PageSpeed Insights marks with the largest savings, and leave the rest.

How to confirm the improvement

After changes, compare First Contentful Paint and Largest Contentful Paint in lab tests, look at the filmstrip to see whether content appears earlier, and check that the render-blocking list is shorter. Then watch field data over the following weeks. If First Contentful Paint improved but LCP did not, the main image or server response may now be the bigger bottleneck.

How Site AI Audit helps

Site AI Audit runs Google PageSpeed for mobile as part of each check and reports Core Web Vitals, server response time, compression and page weight. When render-blocking resources slow down the first paint, the report explains the problem in plain words with a suggested fix, such as deferring scripts below the fold, and ranks it against your other findings. You can check your site for free.

Related reading

• How to Improve Largest Contentful Paint (LCP) on Any Website
• Interaction to Next Paint (INP): How to Fix Slow Interactions
• How to Read a PageSpeed Insights Report Without Guesswork

The bottom line

Render-blocking resources are files the browser must process before painting. Defer scripts that can wait, remove CSS and JavaScript the page does not use, keep the CSS needed for the first screen small, and make fonts non-blocking. Change one thing at a time and test the interactive parts of your site after every step.

FAQ

What are render-blocking resources?

They are CSS files and synchronous JavaScript files that the browser must download and process before it can display the page. By default, stylesheets in the head and scripts without defer or async are render-blocking. They delay First Contentful Paint and often LCP.

Is it safe to defer all JavaScript?

Not always. Scripts that other inline code depends on, or that must run before content is shown, can break when deferred. Defer scripts one group at a time and test menus, forms and other interactive features after each change.

Should I use async or defer?

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 scripts or the page structure. Both stop the script from blocking parsing.

What is critical CSS?

Critical CSS is the minimum set of styles needed to render the visible top of the page. Inlining it in the head lets the browser paint immediately, while the full stylesheet loads without blocking. It works well but must be regenerated when the design changes.

Can I remove all render-blocking warnings?

Often not, and you do not need to. Some CSS must block rendering to avoid unstyled content, and some third-party scripts must load early. Aim to remove the largest items and to get good Core Web Vitals rather than an empty list.