Render-blocking JavaScript in the head: how to fix
Synchronous scripts in the head block the browser from painting, delaying LCP. Find render-blocking scripts free and add defer or async to unblock rendering.
What it means
The page loads one or more synchronous <script src> elements in its <head> — scripts with no defer, no async, and not type="module". The browser must stop parsing the HTML, download each script, and execute it before it can continue building the page. That pause delays the first paint and pushes back Largest Contentful Paint (LCP), one of the Core Web Vitals.
Why it matters
Core Web Vitals are part of Google's page experience signals, and LCP is the metric most directly harmed by render-blocking scripts. When a synchronous script sits in the head, the parser halts at that tag: it cannot render anything below it, cannot start painting the main content, and cannot begin the LCP element's work until the script has fully loaded and run. A few blocking scripts can add hundreds of milliseconds to seconds of delay on slower connections — exactly the range that moves a page from "good" to "needs improvement" on LCP. This is a static-HTML lab signal, not a field measurement, but it is one of the most actionable performance findings available from the HTML alone because the fix is a small attribute change rather than a re-architecture.
How to fix it
- Identify each blocking <script src> in the head.
- Add defer to scripts that can run after the HTML is parsed (most third-party and app scripts) — they download in parallel and execute in order without blocking the parser.
- Add async to independent scripts whose execution order does not matter (analytics, standalone widgets).
- Convert ES-module entry points to type="module", which defers by default.
- Keep truly critical inline configuration inline — inline scripts without a src are not the target here.
Example
<head>
<script src="/js/analytics.js"></script>
<script src="/js/app.js"></script>
</head><head>
<script src="/js/app.js" defer></script>
<script src="/js/analytics.js" async></script>
</head>defer runs the script after HTML parsing in document order; async runs it independently. Use defer for app code that touches the DOM, async for fire-and-forget scripts like analytics.
When it's not a problem
Crawlinx counts only <script src> elements in the <head> that lack defer/async and are not type="module". Inline configuration scripts are not counted, type="module" scripts are excluded because they defer by specification, and application/ld+json blocks are excluded because they are data, not executable code. Because this is a lab proxy rather than a field CWV measurement it is a warning: a page can still pass field LCP despite blocking scripts if the network and device are fast. Treat it as a strong lead to investigate, and prioritize scripts loaded before the LCP element.
How Crawlinx detects it
At parse time we count external <script src> tags in the <head> that carry neither defer nor async and are not type=module (modules are deferred by default). Each such script blocks the parser, so the count is reported.
How common is it?
6948 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.
FAQ
- What is a render-blocking script?
- A synchronous <script src> in the head. The browser must stop parsing HTML, download, and execute it before continuing — delaying first paint and Largest Contentful Paint.
- Should I use defer or async?
- defer for scripts that read or modify the DOM and depend on parse order (most app code). async for independent scripts like analytics where execution order doesn't matter.
- Is type=module render-blocking?
- No. ES modules are deferred by default, so a <script type="module"> in the head doesn't block parsing. That's why this check ignores them.
Related guides
Audit your own site — free
157 checks, internal PageRank, render-diff. No signup, results in ~30s.