Render-Blocking Resources Explained

When a browser loads a page, it builds what you see in stages. Certain files make it stop and wait before showing anything. These are render-blocking resources. Reducing them is one of the most effective ways to make a page appear sooner.

What blocks rendering

CSS. The browser won't paint the page until it has processed the stylesheets in the head, because it doesn't want to show unstyled content. Stylesheets are render-blocking by design.

JavaScript. A normal script tag in the head blocks the browser from continuing to read the HTML until the script downloads and runs. That delays everything below it.

Fonts, images, and other resources aren't strictly render-blocking in the same way, but they can still delay the moment important content shows. See choosing web fonts.

Why it matters

Render-blocking files directly delay when visitors see content, hurting metrics like First Contentful Paint and Largest Contentful Paint. See how to improve LCP and Core Web Vitals explained.

How to find them

Speed-testing tools often flag "eliminate render-blocking resources" and list the files. See how to test website speed. Check your browser's developer tools waterfall chart to see what loads before the page paints.

Fixing blocking JavaScript

Add the right attribute:

• defer downloads the script while the HTML is read and runs it after the page structure is ready, in order. This suits most scripts that need the page content.
• async downloads in parallel and runs as soon as ready, in no guaranteed order. This suits independent scripts such as analytics.

Also:

• Move scripts to the end of the body where deferring isn't possible
• Remove scripts you don't need. See third-party scripts and website speed
• Combine small files wisely. With modern protocols, many small files aren't as costly as they used to be. See HTTP/2 and HTTP/3 explained
• Minify what remains

Test after each change, because deferring a script that other code depends on can break features.

Fixing blocking CSS

• Remove unused CSS. Large frameworks and themes often include much more than you use.
• Inline critical CSS. Put the small amount of CSS needed for above-the-fold content directly in the page, and load the rest later. This works well on simple sites and with build tools that can extract it.
• Split by purpose. Use media attributes so print or large-screen styles don't block small-screen rendering.
• Keep it small. A lean stylesheet loaded early is better than several large ones.
• Avoid chains. Stylesheets that import other stylesheets create sequential waits.

Fonts

Use font-display so text appears with a fallback while a custom font loads, and preload the one or two critical font files.

Plugins and builders

On WordPress and similar platforms, caching and optimization plugins can defer scripts and inline critical CSS, but their automatic settings can break layouts or features. Change one setting at a time and test. See how to speed up a WordPress site.

Don't overdo it

Aggressive deferral can cause flashes of unstyled content or layout shifts. Check your pages visually. See how to fix layout shift.

The bottom line

Make CSS small and critical, and make JavaScript wait its turn with defer or async. The sooner the browser can paint, the faster your site feels.