Render-blocking resources
A render-blocking resource is a stylesheet or a script the browser must download and process before it draws the page. Until that is done the visitor sees a blank screen. On WordPress they are the CSS and JavaScript files that themes and plugins load in the head.
- By
- WP Ministry
- Published
In short
- A stylesheet blocks the first draw. So does a script in the head with no defer or async. Images, fonts and scripts at the end of the page do not.
- Since WordPress 6.3, the theme or plugin that loads a script can ask for defer or async. A script loaded without either still blocks.
- PageSpeed Insights lists these files under "Render-blocking requests". Older reports call the same list "Eliminate render-blocking resources".
A render-blocking resource is a file the browser must download and process before it draws anything of the page. Until that is done, the visitor looks at a blank screen. In practice it is a stylesheet or a script in the page's <head>.
What blocks:
- A stylesheet. CSS blocks by default. The browser will not draw the page until it has downloaded and processed it.
- A script in the head with no
defer,asyncortype="module". Strictly, it stops the browser reading the HTML. Because it sits above all the content, the effect is the same.
What does not:
- Images and fonts. The browser draws first and fills them in.
- A script with
deferorasync, or one placed at the end of the page. - A stylesheet whose
mediadoes not match the screen, such asmedia="print".
On WordPress, themes and plugins load their files through wp_enqueue_style() and wp_enqueue_script(). A stylesheet gets media="all" unless its author says otherwise. A script goes in the head and blocks unless its author asks for the footer or, since WordPress 6.3, for a loading strategy of defer or async.
Where you meet it
- PageSpeed Insights. The insight "Render-blocking requests" lists each file and how long it took.
- Older reports and guides. Before Lighthouse 13, released in October 2025, the same list was an audit named "Eliminate render-blocking resources", shown under Opportunities.
- The page's source. The
<link rel="stylesheet">and<script src="...">tags between<head>and</head>.
What goes wrong
- Deferring a script breaks something. A deferred script runs after the HTML has been read. Inline code in the page that expects it to be loaded already runs first and fails. How to fix render-blocking CSS and JavaScript works through this one file at a time.
- A script stays blocking although it was asked to defer. WordPress protects the order scripts run in. If a blocking script depends on the deferred one, or inline code is attached after it, WordPress treats it as blocking.
- Inlined critical CSS causes faults. Chrome's documentation warns that inlining CSS is easy to get wrong, and says most sites can meet the performance targets without it.
- The list is chased for its own sake. The insight carries no weight in the score, which is worked out from the metrics. What these files cost is time before the main content appears. See how to fix Largest Contentful Paint and Core Web Vitals.
- Minifying is expected to fix it. Minification makes a file smaller, and a smaller file in the head still blocks. How to minify CSS and JavaScript covers what it is good for.
How to look at yours
View the page's source and read the part between <head> and </head>. A <script> tag there with a src and no defer or async, and a <link rel="stylesheet"> whose media is all, are the usual candidates for the report's list.
Common questions
Is all CSS render-blocking?
By default, yes: the browser waits for a stylesheet before it draws. A stylesheet whose media attribute does not match the current screen, such as one for print, does not hold the page up.
What is the difference between defer and async?
Both let the browser keep reading the page while the script downloads. A deferred script runs once the page has been read, in the order the scripts appear. An async script runs as soon as it has loaded, so the order is not guaranteed.
Does WordPress defer scripts by itself?
Only when the code that loads a script asks for it. Since version 6.3, a theme or plugin can pass a strategy of defer or async when it registers or enqueues a script. Without one, WordPress loads the script the blocking way, as it always did.