The fix, in one snippet
<script src="/js/app.js" defer></script>
<script src="https://cdn.example.com/analytics.js" async></script>Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We count <script src="..."> elements inside <head> that carry neither async nor defer, and report pages with three or more. Stylesheets in the head are counted alongside them for context, since they block rendering too.
Why it matters
A classic script tag is a full stop for the HTML parser: it must fetch, parse and execute the file before reading the next line of markup. Three such scripts in the head means three sequential round trips before the body is even looked at.
The effect lands squarely on First Contentful Paint and Largest Contentful Paint. On a fast connection it is tens of milliseconds; on a mobile connection with high latency it is often more than a second of blank screen.
The scripts that do this are rarely essential: tag managers, analytics, chat widgets and A/B testing snippets, all of which are asked to load first precisely because they are third-party and nobody wants to own the decision to defer them.
How to fix it
defer is the right default for anything that touches the DOM: it downloads in parallel, executes after parsing, and preserves order between deferred scripts. async suits independent third-party scripts where order does not matter.
<!-- blocks the parser -->
<script src="/js/app.js"></script>
<!-- downloads in parallel, runs after the document is parsed -->
<script src="/js/app.js" defer></script>
<!-- independent, order irrelevant -->
<script src="https://cdn.example.com/analytics.js" async></script>Inline the small amount of CSS needed for the first screen and load the rest asynchronously if stylesheets are the bottleneck. Then re-measure: Lighthouse's "Eliminate render-blocking resources" audit lists exactly how much each one costs.
Where this fits
Render-blocking scripts in the head is check 3 of 7 that the seo & site health audit runs under technical seo and speed, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits HTML served uncompressed (medium), where hTML served without gzip or brotli transfers several times more bytes than it needs to. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Render-blocking scripts in the head closes one route in. Immediately below it: Slow server response, where how long the server took to return each page; http:// references on HTTPS pages, where links from an HTTPS page to http:// URLs cost a redirect on every click and expose the first request; Language attribute missing, where the lang attribute on <html> tells screen readers which pronunciation to use and search engines which language to file the page under.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Render-blocking scripts in the head (medium severity)
Scanner check id: seo-render-blockingThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.