Skip to content

Performance

How to fix render-blocking scripts

The browser stops parsing your HTML, fetches each one, and executes it before drawing anything. Nothing appears on screen until they all finish, which is the most common reason a fast server still produces a slow first paint. Adding `defer` is usually all it takes.

What 13x checks

This is rule performance.blocking-scripts in the public registry: No render-blocking scripts in the head. It runs on every audit, against the pages we actually fetched, and its result is derived from the response rather than estimated.

Surface
Performance
Score weight
8 of the readiness score
Scope
Reported as skipped when the page renders only with JavaScript
Applies
To every site

Registry version 2026-07-30. Every rule is published, and the audit is deterministic — the same page produces the same finding every time.

The fix

The same text the audit hands you when this check fails on your own site.

Blocking scripts in <head>: .

The browser stops parsing your HTML, downloads each one, and runs it before drawing anything:

html code
<!-- Blocks rendering -->
<script src="/analytics.js"></script>

<!-- Downloads in parallel, runs after parsing. Order preserved. -->
<script src="/analytics.js" defer></script>

<!-- Downloads in parallel, runs whenever ready. No order guarantee. -->
<script src="/analytics.js" async></script>

Use defer unless the script must run immediately. Use async for independent third-party tags like analytics. type="module" is deferred by default.

The one case where a blocking script is right is an inline snippet preventing a theme flash — keep that one, defer the rest.

Framework-specific versions

Where the change differs enough to be worth writing out separately.

Does your site have this problem?

13x checks this and 112 others against your live URL in about 30 seconds. No account, and every finding comes with the fix for your framework.

No signup. Results in 30 seconds.

More performance checks