Async vs Defer: Optimizing JavaScript Loading for Faster Websites
Cover photo by Brett Jordan on Unsplash
When you add a <script> tag to the <head> of your HTML, you are asking the browser to stop everything, fetch that file, and run it before showing any content. For a user on a slow connection, this simple action can stare at a blank white screen for seconds.
Note: The following examples assume the script is placed inside the <head> tag.
Modern web development offers us two powerful attributes to solve this: async and defer. But which one should you choose?
Let's break it down with a simple analogy: The Moving Crew.
#1. The Default Behavior (No Attribute)
Imagine a Moving Crew (The Browser) carrying boxes (HTML) into a new house. Suddenly, the foreman shouts "STOP! We need to read this instruction manual (JavaScript) right now!"
The entire crew stops. They wait for the manual to be delivered. Then they stand around while the foreman reads it. Only after he's finished do they start carrying boxes again.
In Technical Terms: The HTML parser pauses. The script is downloaded and executed immediately. HTML parsing only resumes after the script finishes running. The browser completely stops building your page during this time (represented by the Red Block in the diagram).
<script src="script.js"></script>#2. The async Attribute (The Impatient Helper)
Now imagine the foreman says, "Order the manual, but keep working until it gets here."
The crew keeps carrying boxes while the manual is being delivered. HOWEVER, as soon as the manual arrives, the courier interrupts the crew. "STOP! Read this NOW!" The crew stops, reads the manual immediately, and then resumes work.
In Technical Terms: The script is downloaded in parallel with HTML parsing. However, the moment the download finishes, the HTML parser pauses to execute the script. The browser stops building your page only while the script runs (represented by the Red Block in the diagram).
- Pros: Good for independent scripts (like tracking pixels or ads) that don't care about the DOM or other scripts.
- Cons: Execution order is not guaranteed. If you have two async scripts, the smaller one might run first, breaking dependencies.
<script async src="script.js"></script>#3. The defer Attribute (The Patient Professional)
This time, the foreman says, "Order the manual, keep working, and when it arrives, just put it on the desk. We will read it after all the boxes are moved in."
The crew works without interruption. The manual arrives in the background. Once the house is completely empty (HTML parsing finished), they read the manual.
In Technical Terms: The script is downloaded in parallel with HTML parsing. Execution is deferred until the HTML parsing is complete. The browser NEVER pauses parsing to deal with the script (Notice: No Red Block in the diagram).
- Pros: Non-blocking. Respected execution order (scripts run in the order they appear in the DOM).
- Cons: Not suitable if the script needs to modify the page before it finishes loading (rare nowadays).
<script defer src="script.js"></script>#Summary Comparison
| Feature | <script> | <script async> | <script defer> |
|---|---|---|---|
| Download | Blocks HTML | Parallel | Parallel |
| Execution | Immediate (Blocks) | Immediate (Blocks) | After HTML Parsing |
| Order | Guaranteed | Random (First come, First serve) | Guaranteed |
| Use Case | Critical UI fixes (rare) | Ads, Analytics, Tracking | App Logic, UI Interactions |
#Which One Should You Use?
Rule of Thumb: Always use defer.
In 90% of modern web development cases, defer is the winner. It gives you the best of both worlds: parallel downloading (speed) and ordered execution after the DOM is ready (safety).
Use async only for third-party scripts that:
- Are independent (don't rely on other scripts).
- Don't need to modify the DOM immediately.
- Examples: Google Analytics, Facebook Pixel, Ad Scripts.
