If defer is so great, why isn't all JavaScript deferred?

If defer makes pages load faster and prevents rendering bottlenecks, why is it not the default for every JavaScript file?

The answer is not that developers forgot. Script loading order is behavior—change the order and you can change the page.

The short answer

A deferred external script downloads in the background, then runs after the HTML document has been parsed. That usually helps performance because the browser can keep building and painting the page instead of stopping at every script tag.

Some scripts must run before the page is visible

There are specific scenarios where you intentionally want a small script to block rendering until it finishes its job. That sounds bad in a performance audit, but it can be better than letting the page visibly change after the user has already seen it.

A/B testing

If you are testing two versions of a page, the script needs to decide which version to show before the first paint. If you defer that logic, the user may see Layout A load and then a split second later watch it jump to Layout B. That flicker is distracting, measurable, and usually worse than a tiny intentional delay.

Dark mode and theme preferences

Theme scripts often need to read a saved preference before the HTML renders. If a user prefers dark mode but the theme script is deferred, the browser may flash a bright default page before switching to the dark theme.

The inline script dependency problem

The defer attribute only applies to external scripts with a src attribute. It does not make inline scripts wait.

That creates a common dependency failure:

<script src="jquery.js" defer></script>

<script>
    // Inline code that expects jQuery to exist.
    $(".menu").show();
</script>

Because jquery.js is deferred, the browser continues parsing the page and immediately runs the inline script. The inline script tries to use jQuery before jQuery has executed, throws an error, and the feature breaks.

You can fix this by moving the inline code into the deferred bundle, waiting for the right lifecycle event, or removing the dependency entirely. But on existing sites, blindly adding defer can expose years of hidden ordering assumptions.

Legacy code and document.write()

In the early web, a common way to inject content into a page was document.write(). You still see it in older ad tags, widgets, and third-party snippets. The command writes HTML into the document while the browser is reading it from top to bottom.

That timing matters. If a deferred script calls document.write() after the browser has finished parsing the page, the browser may treat it as a write to an already-closed document. In the worst case, it can wipe out the current page and replace it with whatever the script wrote.

Third-party analytics and tracking

Marketing and analytics teams often want tracking scripts to load as fast as possible. Google Analytics, Meta Pixel, heat-mapping tools, and attribution scripts are not usually needed to render the page, but they may be needed to capture the earliest user interactions.

If a visitor lands, clicks quickly, and leaves before a deferred analytics script runs, the visit or click might not be recorded. That does not mean tracking scripts should always be render-blocking. It does mean the decision is a tradeoff between performance, data completeness, privacy, and business requirements.

The modern rule: defer what you can, block what you must

You cannot defer everything, but the instinct is correct. Modern web development pushes as much JavaScript as possible out of the render-blocking path. The best sites usually have only a small amount of critical early JavaScript and defer nearly every other external file.

FAQ: render-blocking vs deferred scripts