How to fix render-blocking resources

By Matt Kerr·Published 10 October 2026

A render-blocking resource is a stylesheet or a script in the head that the browser must download and read before it can paint anything. The fix is two moves. Add defer to the scripts the first screen does not need, and load the stylesheets the first screen does not need after it. Keep what the first screen needs, and nothing else, in the way.

What counts as blocking

Two things stop the first paint.

• A script with a src and no async or defer. The browser stops reading the page, fetches the file, runs it, and only then carries on. A script with type="module" is deferred by default, so it does not block.
• A stylesheet with no media restriction. The browser will not paint until it has every such stylesheet, because painting without one would flash unstyled text.

Inline <style> blocks make no request, so they are not part of this. Putting the few rules the first screen needs inline is a normal way to keep one file off the critical path.

Scripts: add defer

defer downloads the file while the page is read and runs it after the page is parsed, in the order written. That is the right choice for most scripts, including the ones that depend on each other.

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

async runs the file as soon as it arrives, in no promised order. Use it only for a script that depends on nothing and that nothing depends on, such as a stats snippet. When in doubt, use defer.

Stylesheets: keep one, load the rest late

Work out which stylesheet draws the first screen: the layout, the type, the header. That one stays as a normal link. The others (a theme for a page you are not on, a widget library, a print sheet) can wait.

<link rel="stylesheet" href="/css/layout.css">
<link rel="stylesheet" href="/css/widgets.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/css/widgets.css"></noscript>

A media="print" stylesheet does not block, because it is not needed for the screen. The onload switches it to every medium once it has arrived. The noscript line is for a visitor with scripts off, who would otherwise never get that file. If you can, merge small files into the one you keep. Fewer files is fewer requests, even over HTTP/2.

A real before and after

I wrote a small fixture site for this page: a typewriter repair workshop, a few pages, four stylesheets and three scripts in the head. I audited it with Docket on 10 October 2026, changed the head, and audited it again. The pages are ours; nothing here is measured on anyone else's site.

Before: all four stylesheets and all three scripts were plain. Docket reported this, in its own words:

3 pages load 5+ render-blocking files
Worst: 7 blocking stylesheets/scripts on the page measured.

The fix it printed was: Add defer to scripts that are not needed for first paint, load non-critical CSS with media="print" onload, and merge the small files that remain. The head after I followed it:

<link rel="stylesheet" href="/css/layout.css">
<link rel="stylesheet" href="/css/reset.css" media="print" onload="this.media='all'">
<link rel="stylesheet" href="/css/theme.css" media="print" onload="this.media='all'">
<link rel="stylesheet" href="/css/widgets.css" media="print" onload="this.media='all'">
<script src="/js/vendor.js" defer></script>
<script src="/js/app.js" defer></script>
<script src="/js/analytics.js" defer></script>

That left 1 blocking file on each page, down from 7, and Docket stopped reporting the page. Nothing visible changed, because the stylesheets I moved were not needed for the first screen. Whether a stylesheet is needed for the first screen is the one judgement here, and a crawler cannot make it for you.

What Docket counts, and what it cannot see

The check counts the blocking files on each page it crawled and reports the pages with five or more. It reads the markup, as a browser's first pass would.

• It counts a blocking script wherever it sits. A plain script at the very end of the body costs the content above it much less than one in the head, and Docket counts both the same. If every blocking file Docket names is at the end of the body, read the finding as an overstatement.
• It does not know which stylesheet draws the first screen. That is why the fix above asks you to decide.
• It does not measure Largest Contentful Paint. Blocking files delay the first paint, which is part of it, and the finding says so. The measured value for your page is in PageSpeed Insights or Search Console. A browser run such as Lighthouse measures one page in detail, and Docket counts the same defect across every page it crawls; see Docket and Lighthouse side by side.

When it is not worth doing

A page with two blocking files has little to gain, and the check stays quiet below five for that reason. If the finding names a handful of pages on a large site, fix the shared template first, since one change in the head fixes all of them. A slow server is a different cause, covered in how to reduce server response time and how to fix compression and caching, and images that push the page around are covered in how to fix layout shift.

Common questions

What does render-blocking mean?

The browser has to download and read the file before it can paint anything. A plain script in the head and a stylesheet with no media restriction both do that.

Should I use defer or async?

Use defer for most scripts. It runs them after the page is read, in the order written. Use async only for a script that depends on nothing and that nothing depends on.

Will loading CSS with media=print and onload break my page without JavaScript?

It can, so add a noscript link to the same file. Visitors with scripts off then get the stylesheet normally.

Does Docket measure Largest Contentful Paint?

No. It counts the blocking files in the markup of every page it crawls. The measured value for a page comes from PageSpeed Insights or Search Console.