What makes a resource render-blocking?

A resource in the head that the browser must fetch and process before it can safely paint the page. A plain without async or defer blocks HTML parsing outright, because the script might document.write or otherwise change what follows it. A lets parsing continue but blocks painting, because the browser refuses to show unstyled content that would immediately reflow once the CSS arrives.

Does async or defer improve my LCP score?

Indirectly, yes, for scripts. Removing a blocking script from the head lets the browser reach and paint the rest of the page sooner, which is often exactly when the LCP element becomes visible. Stylesheets need a different technique since they cannot simply be deferred without a flash of unstyled content: inlining critical CSS and loading the rest asynchronously is the equivalent fix for CSS.

What is critical CSS and is it worth doing?

Critical CSS is the small subset of styles needed to render what is visible in the initial viewport, inlined directly in the head so the browser never has to wait on an external stylesheet to paint that content. The rest of the CSS loads without blocking. It is worth doing on pages where LCP is capped by CSS download time, but it adds a build step and needs to be regenerated when the above-the-fold markup changes, so it is not worth it for every page on every site.

Can I just defer every script to fix render blocking?

Not blindly. defer is the safe default for most application scripts because it preserves execution order, but scripts that intentionally run before the page renders, such as a theme-switcher that must set a class before first paint to avoid a flash of the wrong theme, need to stay blocking on purpose. Check what a script actually depends on before moving it.

Why do third-party tags cause the worst render-blocking problems?

Because they are usually installed exactly as the vendor's snippet says, which is a plain blocking script tag in the head, and because their file size and behaviour are outside your control and can change without warning. A tag manager, chat widget or A/B testing script is frequently the single largest blocking resource on a page, and the fix is almost always to load it with defer or async unless the vendor gives a specific reason it must run first.

Does render-blocking CSS or JS affect INP as well as LCP?

Mainly LCP and first paint, since render blocking is about what delays the page appearing at all. INP is measured after the page is interactive and is driven more by long JavaScript tasks running on the main thread during and after interactions. A heavy blocking script can still hurt both: it delays paint, and once it does run, a large synchronous script can also tie up the main thread.

Render-Blocking Resources: Why Your Page Waits Before It Paints

What blocking actually means

The browser is not being slow. It is obeying instructions to wait, and those instructions are in your markup.

A browser parses HTML top to bottom. When it reaches an ordinary <script src> in the head, it stops parsing, fetches the file, runs it, and only then continues, because the script might rewrite the document beneath it. Stylesheets block differently: parsing continues, but the browser will not paint until the CSS has arrived, because painting first would flash unstyled text and then reflow it. In both cases the page is ready in memory and deliberately withheld from the screen. Every blocking file in the head adds its full round trip to the time before anything appears.

Why this shows up in your Core Web Vitals

Blocking resources push out the exact moment Largest Contentful Paint measures.

LCP records when the largest element in the viewport finishes rendering. If painting cannot start until four stylesheets and two scripts have downloaded, LCP cannot be earlier than that, no matter how well optimised the image itself is. Teams often compress the hero image and see the score barely move, because the image was never the constraint: the wait before painting was.

This is also why lab and field numbers diverge. On a fast office connection six blocking files cost little. On a mid-range phone on mobile data each one is a fresh round trip, and the same page takes multiples longer. Core Web Vitals explained covers what the thresholds are; this page covers the most common reason a site misses them.

Fixing scripts: defer, async, or move

Three attributes cover almost every script on a normal page. Choosing between them takes seconds once the difference is clear.

defer

Downloads in parallel with parsing and runs after the HTML is parsed, in document order. This is the right default for almost every script a page loads: application code, widgets, anything that reads the DOM.

Order is preserved, so a script that depends on one earlier in the page still works. If you are unsure which attribute to use, defer is the safe answer.

async

Downloads in parallel and runs the moment it arrives, interrupting parsing. Order is not guaranteed, so it suits only genuinely independent scripts such as an analytics beacon.

Using async on code with dependencies produces intermittent failures that appear on slow connections and vanish on fast ones, which makes them unusually hard to reproduce.

Move it out of the head

A script with neither attribute placed just before the closing body tag no longer blocks the initial paint, because the parser has already reached the end of the document.

This is the oldest fix and still works, but defer is generally better: it starts the download immediately instead of waiting until the parser arrives, so the file is usually ready sooner.

Third-party tags

Tag managers, chat widgets and A/B testing snippets are frequently installed as plain blocking scripts in the head because the vendor instructions say to.

These are often the largest blocking cost on the page and the least examined. Load them with defer or async unless the vendor gives a concrete reason they must run first, and measure what each one costs before accepting it.

Fixing CSS without breaking the page

Stylesheets cannot simply be deferred, so the approach is different.

Deferring all CSS causes a flash of unstyled content, which is worse than a short wait and damages Cumulative Layout Shift as the page reflows. The working approach is to split it: inline the small amount of CSS needed to render what appears in the viewport first, and load the rest without blocking, commonly by setting media="print" and switching it to all once loaded.

Before reaching for that, check the simpler wins. Many sites block on stylesheets they barely use: an icon font loaded for two icons, a full UI framework for one component, or a print stylesheet that should be media="print" already and therefore never blocking. Removing an unused blocking file is faster and safer than engineering around it, and it is usually the larger saving.

Render-blocking questions, answered

What exactly makes a resource render-blocking?

A resource in the head that the browser must fetch and process before it can safely paint. A plain <script src> without async or defer stops HTML parsing outright, because the script could rewrite what follows it. A stylesheet lets parsing continue but blocks painting, because showing unstyled content and then reflowing it once CSS arrives would look worse than the wait.

Does fixing this actually move my LCP score?

Yes, for scripts directly: removing a blocking script lets the browser reach and paint the rest of the page sooner, often including the LCP element itself. CSS needs a different technique since a stylesheet cannot simply be deferred without a flash of unstyled content; inlining critical CSS and loading the rest asynchronously is the equivalent fix.

Is critical CSS worth setting up?

Where LCP is capped by stylesheet download time, yes. It inlines only the styles needed for what's visible on load, so the browser never waits on an external file to paint that content. It adds a build step and needs regenerating when above-the-fold markup changes, so weigh that against the size of the win on a given page.

Can I just add defer to every script and be done?

Not blindly. defer is the safe default for most application code, but a script that intentionally must run before paint, such as a theme class-setter that prevents a flash of the wrong theme, needs to stay blocking on purpose. Check what a script depends on before moving it.

Why are third-party tags usually the worst offenders?

Because they're installed exactly as the vendor's snippet says, which is typically a plain blocking script in the head, and their size and behaviour are outside your control. A tag manager or chat widget is frequently the single largest blocking resource on the page. Load it with defer or async unless the vendor has a specific reason it must run first.

Does render blocking affect INP too, or just LCP?

Mainly LCP and first paint, since blocking is about delaying the page from appearing at all. INP is measured once the page is interactive and is driven more by long JavaScript tasks on the main thread during and after interactions. A heavy blocking script can hurt both: it delays paint, and once it runs, a large synchronous script can also tie up the thread. See Core Web Vitals explained for the INP thresholds and fixes.

Render-blocking resources