Script Loading: async vs defer - When to Use Each

Easy•

Script Loading Patterns

Browser Runtime

Regular Script

Classic parser-blocking behavior

- Blocks HTML parsing
- Predictable immediate execution

async

Independent script execution

- Downloads in parallel
- Executes when ready (order not guaranteed)

defer

Best default for app bundles

- Downloads in parallel
- Executes after parse, in order

type=module

Module graph semantics

- Deferred by default
- Use async only for independent module timing

Core Lens

Choose by parser blocking risk, execution-order guarantees, and DOM-readiness requirements.

Flow

Parser sees script→

Download→

Execute timing→

DOM ready behavior

Script loading choices are about parser blocking, execution order, and DOM-readiness guarantees. Interview-safe explanations cover regular vs async vs defer; deeper browser-aware explanations include parser interruptions, DOMContentLoaded timing, and module-script behavior.

Asked In

Atlassian

Quick Navigation: Interview-safe vs Deeper Browser Model • Regular Script Loading (No Attribute) • The async Attribute • The defer Attribute • Execution Order and DOM Readiness • Module Scripts • Performance and Common Pitfalls • Best Practices

Quick Decision Guide

Use defer for most application scripts that need predictable order or depend on the parsed DOM.

Use async for independent scripts like analytics, ads, or widgets where execution order does not matter.

Use a plain external <script> without attributes only when parser-blocking behavior is truly required.

type="module" scripts are deferred by default, so they usually behave more like defer than classic blocking scripts.

Interview-safe vs Deeper Browser Model

Interview-safe model

Use this in interviews:

•plain <script src> blocks parsing

•async downloads in parallel and executes as soon as ready

•defer downloads in parallel and executes after parsing, in document order

•type="module" behaves like deferred by default

Deeper browser model

For senior-level answers, add:

•parser blocking is about execution time, not just download time

•async scripts can still interrupt parsing when they execute

•deferred classic scripts run before DOMContentLoaded

•module scripts are deferred by default, and defer has no extra effect on them

Practical framing

Ask two questions:

1. Do I need deterministic execution order?

2. Must this run before the DOM is parsed?

If order or parsed DOM matters, default to defer. If fully independent, use async.

Regular Script Loading (No Attribute)

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

How It Works

For a classic external script without async or defer:

1. HTML parsing stops

2. The browser fetches the script

3. The script executes immediately

4. HTML parsing resumes

Mental Model

> The parser hits the script tag and must wait.

Why It Matters

Parser-blocking scripts delay visible progress because the browser cannot continue parsing the document until that script is ready and executed.

When It Still Makes Sense

•tiny critical inline bootstrap code

•code that must run before later markup is parsed

•rare compatibility or sequencing cases where blocking is intentional

Example

<head>
  <script>
    window.APP_CONFIG = { apiBase: '/api' };
  </script>
</head>
<body>
  <script src="app.js"></script>
</body>

Trade-off

Blocking is simple and predictable, but usually the worst option for page startup performance.

The async Attribute

The `async` Attribute

<script async src="analytics.js"></script>

How It Works

For a classic external script with async:

1. HTML parsing continues

2. The script downloads in parallel

3. As soon as the script is ready, it executes immediately

4. That execution may happen before parsing completes

Mental Model

> Download early, run whenever ready.

Key Characteristics

Advantages

•non-blocking download

•fast execution once the resource is ready

•good for scripts that do not depend on document order or the parsed DOM

Disadvantages

•execution order is not guaranteed between multiple async scripts

•can run before the DOM is fully parsed

•can interrupt parsing when it executes

Best Use Cases

•analytics

•ads

•third-party tags

•independent widgets

•scripts that do not depend on other scripts

Common Mistake

<!-- ❌ Order is not guaranteed -->
<script async src="jquery.js"></script>
<script async src="plugin.js"></script>

If plugin.js expects jQuery, this can break because plugin.js may execute first.

Better Alternative

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

Interview Takeaway

Use async when independence matters more than ordering.

The defer Attribute

The `defer` Attribute

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

How It Works

For a classic external script with defer:

1. HTML parsing continues

2. The script downloads in parallel

3. Execution waits until parsing finishes

4. Multiple deferred classic scripts execute in document order

Mental Model

> Download now, execute later, preserve order.

Key Characteristics

Advantages

•non-blocking download

•runs after parsing completes

•preserves execution order across deferred classic scripts

•avoids parser interruption during download phase

•strong default for application code

Disadvantages

•does not run as early as async

•not useful when immediate execution is required

Why It’s Often the Best Default

Application scripts usually need at least one of these:

•parsed DOM

•predictable order

•stable startup sequence

That makes defer a better default than async for most app bundles.

Example

<script defer src="runtime.js"></script>
<script defer src="vendor.js"></script>
<script defer src="app.js"></script>

These execute after parsing, in the same order they appear.

Important Detail

Deferred classic scripts run before DOMContentLoaded, which means that event waits for them to finish.

Execution Order and DOM Readiness

This is where interview answers usually get separated.

🔥 Insight

The real choice is often not “fast vs slow.” It is unpredictable early execution vs predictable late execution.

Comparison

Regular script

•blocks parsing

•executes immediately

•order follows document order

`async`

•does not block download

•executes as soon as ready

•order is not guaranteed

•may run before DOM is fully parsed

`defer`

•does not block download

•executes after parsing

•order is preserved

•good fit for DOM-dependent scripts

Rule of Thumb

•Need predictable order? → defer

•Need DOM to be parsed first? → defer

•Script is fully independent? → async

•Need immediate parser-blocking behavior? → plain script

Module Scripts

<script type="module" src="app.js"></script>

Module scripts are deferred by default.

What That Means

•they download in parallel with parsing

•they execute after parsing by default

•defer has no effect on them

Important Nuance

You can still mark a module script as async:

<script type="module" async src="app.js"></script>

In that case, the module and its dependency graph are fetched in parallel and evaluated as soon as available.

Practical Takeaway

If you are using modern ES modules, you usually do not need to add defer manually.

Performance and Common Pitfalls

What Actually Improves Performance

•avoid parser-blocking scripts on the critical path

•use defer for main application bundles

•use async for truly independent third-party scripts

•reduce script size and count where possible

Common Pitfalls

1. Using `async` for dependent scripts

<script async src="vendor.js"></script>
<script async src="app.js"></script>

If app.js depends on vendor.js, this is fragile.

2. Blocking parsing with non-critical third-party code

<script src="analytics.js"></script>

This slows parsing for no good reason.

3. Assuming `async` waits for DOM

It does not. An async script can execute before the DOM is fully parsed.

4. Adding `defer` to module scripts expecting different behavior

Module scripts already defer by default.

Best Practices

Decision Tree

Does the script need predictable order or parsed DOM?
├─ Yes → use defer
└─ No → is it independent?
   ├─ Yes → use async
   └─ No → use defer

Common Patterns

Pattern 1: Modern Web App

<body>
  <div id="root"></div>

  <script defer src="runtime.js"></script>
  <script defer src="vendor.js"></script>
  <script defer src="app.js"></script>
</body>

Pattern 2: App + Analytics

<body>
  <script async src="analytics.js"></script>
  <script defer src="app.js"></script>
</body>

Pattern 3: ES Modules

<body>
  <script type="module" src="app.js"></script>
</body>

Final Rule of Thumb

For most application code, defer is the safest default.

Use async only when the script is independent and order does not matter.