Render-Blocking Resources: How to Fix Them

Quick answer: Render blocking resources are CSS and JavaScript files the browser must download and process before it can draw anything on screen. Each one adds delay before the visitor sees content. To fix them, defer or async non-essential scripts, inline the small amount of CSS needed for the first screen and load the rest later, remove code you do not use, and be careful with third-party tags and web fonts. PageSpeed Insights lists the files causing the problem under “Eliminate render-blocking resources.”

Why browsers block rendering

When a browser loads a page, it reads the HTML from top to bottom. When it meets a stylesheet in the head, it stops painting until that CSS arrives, because drawing the page without styles would cause a flash of unstyled content and then a jarring redraw. When it meets a normal script tag, it stops parsing HTML entirely until the script downloads and runs, because the script might change the page.

That behavior is sensible, but it means every stylesheet and synchronous script in the head stands between the visitor and the first visible pixel. On a fast desktop connection the delay might be small. On a mid-range phone over a patchy mobile network, a handful of blocking files can add seconds.

The metrics most affected are First Contentful Paint, which measures when anything appears, and Largest Contentful Paint, which measures when the main content appears. Largest Contentful Paint is one of the Core Web Vitals Google introduced this year and plans to use as part of a page experience ranking signal in 2021.

How to find render-blocking resources

PageSpeed Insights and Lighthouse

Run your page through PageSpeed Insights. Under Opportunities, look for “Eliminate render-blocking resources.” It lists each blocking file with its size and the potential time saving. The same audit appears in Lighthouse inside Chrome DevTools.

Test your most important templates, not only the homepage. A blog post template, a product page and a landing page may load very different files.

The Coverage tab in Chrome DevTools

Open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac), type “Coverage” and reload the page. You will see each CSS and JavaScript file with the percentage of bytes that were actually used. It is common to find a stylesheet where 90 percent of the rules are unused on that page, because it contains styles for the whole site.

A waterfall view

WebPageTest and the Network tab in DevTools show a waterfall of requests. Files that load before the first paint and hold it back are the ones to focus on.

Fixing render-blocking JavaScript

Use defer for most scripts

Adding the defer attribute tells the browser to download the script in parallel while it keeps parsing HTML, and to run it only after the document has been parsed. Deferred scripts run in the order they appear.

<script src="/js/main.js" defer></script>

For most site scripts, such as menus, sliders, form validation and analytics helpers, defer is the safest choice. The page can render, and the scripts run shortly after.

Use async for independent scripts

The async attribute also downloads in parallel, but runs the script as soon as it arrives, in no particular order. It suits scripts that do not depend on anything else and that nothing depends on, such as some analytics or ad tags.

<script src="https://example.com/tag.js" async></script>

Do not add async to scripts that depend on a library like jQuery. They may run before the library loads and throw errors.

Move scripts out of the head

If you cannot add attributes, moving scripts to just before the closing body tag has a similar effect for rendering. Defer is usually better because the download starts earlier.

Remove what you do not need

The fastest script is one you never load. Look for:

Plugins that load JavaScript on every page but are used on one
Old libraries kept for a feature you removed
Duplicate copies of jQuery loaded by a theme and a plugin
Tracking pixels from campaigns that ended

Our guide to third-party scripts and speed covers how to audit tags that marketing tools add over the years.

Fixing render-blocking CSS

CSS is trickier, because the page genuinely needs some styles to render properly. The goal is to deliver just enough CSS for the first screen as quickly as possible, then load the rest without blocking.

Inline critical CSS

Critical CSS is the set of rules needed to style the content visible without scrolling. Inline that small set directly in a style tag in the head, so the browser can paint immediately without waiting for a separate file.

Tools such as the open source Critical package or features in some caching plugins can generate critical CSS automatically. Check the result on several templates, because a generator that only looks at the homepage may miss styles used on other pages.

Load the full stylesheet without blocking

Once critical CSS is inline, load the main stylesheet in a way that does not block rendering. A common pattern uses preload and swaps it into a stylesheet once loaded:

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

The noscript fallback makes sure visitors without JavaScript still get styles.

Use media attributes

A stylesheet with a media attribute that does not match the current device does not block rendering. Print styles are the classic example:

<link rel="stylesheet" href="/css/print.css" media="print">

You can also split large stylesheets by breakpoint so a phone does not block on desktop-only rules.

Minify and remove unused CSS

Minification strips whitespace and comments. It reduces file size but does not change what blocks rendering, so treat it as a complement to the techniques above. Our article on how to minify CSS and JavaScript explains the trade-offs.

Removing unused CSS has a bigger effect but needs care. Tools like PurgeCSS can strip rules not found in your templates, but they can also remove styles added dynamically by JavaScript. Test thoroughly.

Fonts and third-party CSS

Web fonts loaded from a separate stylesheet, such as a Google Fonts link in the head, are render blocking in two ways. The font CSS blocks rendering, and the browser may hide text until the font file arrives.

Practical fixes:

Add display=swap to the Google Fonts URL, or font-display: swap in your own @font-face rules, so text shows in a fallback font while the web font loads.
Use preconnect to the font host so the connection starts early.
Load fewer weights and styles.
Self-host fonts if you want full control.

Icon fonts have similar issues. We cover alternatives in our piece on icon fonts and performance.

What about HTTP/2?

HTTP/2 lets the browser download many files over a single connection, which reduces the cost of having several small files. It does not change the blocking rules. A stylesheet in the head still blocks rendering whether it arrives over HTTP/1.1 or HTTP/2. So HTTP/2 makes it less important to bundle everything into one file, but critical CSS and deferred scripts still matter.

WordPress specifics

On WordPress sites, render-blocking files usually come from the theme and plugins. Options include:

A performance plugin that can defer JavaScript, inline critical CSS and combine files. Test after enabling each feature, because deferring scripts can break sliders and page builders.
Dequeueing plugin scripts on pages that do not use them, using wp_dequeue_script and wp_dequeue_style in a child theme or a small custom plugin.
Choosing a lighter theme when the current one loads large frameworks on every page.

Always test on a staging copy first. A broken checkout or contact form costs more than a slower paint.

A sensible order of work

Run PageSpeed Insights on your key templates and list the blocking files.
Remove scripts and styles you do not need.
Add defer to remaining scripts that do not need to run early.
Fix fonts with font-display and preconnect.
Inline critical CSS and load the main stylesheet without blocking.
Retest and compare First Contentful Paint and Largest Contentful Paint.

Keep a note of each change, so if something breaks you know which step caused it.

FAQ

Can I eliminate all render-blocking resources?

Usually not completely, and you do not need to. Some CSS has to arrive before the page looks right. The goal is to reduce the blocking work to the minimum needed for the first screen.

Does defer delay my analytics?

Slightly, but analytics scripts are usually loaded async already. A brief delay in a tracking script is a fair trade for a faster first paint.

Will these changes affect SEO?

Faster rendering improves user experience, and Google has said page experience signals, including Core Web Vitals, will become part of ranking in 2021. Speed alone will not outrank better content, but slow pages lose visitors before they read anything.

Why did my score drop after I added a plugin?

New plugins often add their own CSS and JavaScript to every page. Check the waterfall to see what was added and whether it can load only where needed.

Next step

Pick your highest-traffic template, run the audit, and work through the list above. If you would rather have someone handle the testing and fixes on your site, our team can help through our Turn visitors into customers services, where speed is part of building pages that convert.