Render-blocking scripts: Crawl Audit check 87

Short answer: a plain <script src> in the <head> makes the browser stop, download and run it before reading the rest of the page. Adding defer or async lets the page carry on. Check 87 warns when PageSpeed finds render-blocking scripts, or, without PageSpeed, when a script in the head has neither.

What Crawl Audit checks

• Full report: PageSpeed's render-blocking result.
• Free check: scripts in the <head> with a src but no defer, async or type="module". Pass if there are none; warning with the count.

What the standards say

• MDN: "Scripts without async, defer or type="module" attributes, as well as inline scripts without the type="module" attribute, are fetched and executed immediately before the browser continues to parse the page."
• defer: "Scripts with the defer attribute will execute in the order in which they appear in the document", after the page is read.
• async: the script "will be fetched in parallel to parsing and evaluated as soon as it is available."
• Module scripts (type="module") are deferred by default.
• MDN is precise about it: "Only script elements in the document's <head> can possibly block rendering." A plain script there blocks the parsing of the page, which holds everything after it up.

<script src="/app.js" defer></script>
<script src="https://example.com/widget.js" async></script>

Which to use

• defer for your own scripts, which often depend on each other's order.
• async for independent scripts, such as analytics, that don't care about order.
• Neither only for the rare script that must run before the page renders, such as one that sets the colour theme to avoid a flash.

Sources

• MDN, <script>: The Script element, checked 3 October 2026.
• Chrome for Developers, Eliminate render-blocking resources.