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.
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 common is it?
78 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.
Related guides
Audit your own site — free
77 checks, internal PageRank, render-diff. No signup, results in ~30s.