How Browsers Read and Execute JavaScript Code
Learn the complete journey of JavaScript code from a script tag to execution in the browser, including parsing, the render pipeline, script loading strategies, and how the event loop coordinates everything.
When you type a URL into your browser and press Enter, a complex chain of events transforms raw HTML, CSS, and JavaScript files into the interactive page you see on screen. JavaScript plays a special role in this process because it can modify both the structure and appearance of the page, which means the browser must coordinate JavaScript execution carefully with the rest of the rendering pipeline.
Think of the browser as a construction crew building a house. HTML provides the blueprints (structure), CSS provides the interior design (styles), and JavaScript is the electrician who can rewire rooms, add new walls, or tear down existing ones while the house is being built. Because the electrician can change anything, the crew sometimes has to pause and wait for the electrician to finish before continuing construction.
This guide walks you through every step of how a browser processes JavaScript, from the moment it encounters a <script> tag to the moment your code runs and updates the page.
The Critical Rendering Path
Before diving into JavaScript specifically, you need to understand the browser's overall rendering pipeline. This is the sequence of steps the browser follows to turn raw files into visible pixels.
| Step | What Happens | Output |
|---|---|---|
| 1. HTML Parsing | Browser reads HTML and builds the DOM tree | DOM (Document Object Model) |
| 2. CSS Parsing | Browser reads CSS and builds the CSSOM | CSSOM (CSS Object Model) |
| 3. JavaScript Execution | Engine runs scripts that may modify DOM/CSSOM | Updated DOM/CSSOM |
| 4. Render Tree | Combines DOM + CSSOM into visible elements | Render Tree |
| 5. Layout | Calculates position and size of each element | Layout geometry |
| 6. Paint | Fills in pixels (colors, borders, shadows) | Painted layers |
| 7. Composite | Combines painted layers into the final image | Pixels on screen |
JavaScript execution (step 3) is unique because it can reach back and modify steps 1 and 2. If your script adds a new <div> to the DOM or changes an element's display property, the browser must recalculate layout and repaint.
How the Browser Discovers JavaScript
The browser encounters JavaScript in three main ways:
Inline Scripts
html<!DOCTYPE html>
<html>
<head>
<title>Inline Script Example</title>
</head>
<body>
<h1 id="title">Welcome</h1>
<script>
// This JavaScript is embedded directly in the HTML
const title = document.getElementById("title");
title.textContent = "Hello from JavaScript!";
</script>
</body>
</html>External Script Files
html<head>
<!-- The browser pauses HTML parsing, downloads app.js, then executes it -->
<script src="app.js"></script>
</head>Module Scripts
html<head>
<!-- Module scripts are deferred by default and support import/export -->
<script type="module" src="main.js"></script>
</head>Parser-Blocking Behavior: Why Script Placement Matters
Here is the single most important concept about JavaScript in the browser: by default, <script> tags block HTML parsing.
When the HTML parser encounters a regular <script> tag, it must:
- Pause parsing the rest of the HTML
- Download the JavaScript file (if it is external)
- Execute the script completely
- Resume parsing the remaining HTML
html<!DOCTYPE html>
<html>
<head>
<title>Blocking Behavior Demo</title>
<!-- Parser stops here, downloads heavy-library.js, executes it -->
<!-- Nothing below this point is parsed until the script finishes -->
<script src="heavy-library.js"></script>
</head>
<body>
<!-- This content is invisible until heavy-library.js finishes loading -->
<h1>This text appears late because the script blocked parsing</h1>
</body>
</html>This blocking behavior exists because the script might call document.write(), which directly modifies the HTML being parsed. The browser cannot safely continue building the DOM if a script might alter the HTML stream.
Why Scripts in the Head Slow Pages Down
Placing large script files in the <head> without defer or async forces the browser to pause rendering until those scripts download and execute. Users see a blank white page during this time. This is the number one performance mistake in beginner HTML/JavaScript projects.
Script Loading Strategies: defer, async, and module
HTML provides three attributes that change how the browser handles script loading. Understanding these is essential for building fast websites.
The defer Attribute
html<head>
<script src="app.js" defer></script>
</head>With defer, the browser:
- Downloads the script in parallel with HTML parsing (no blocking)
- Waits until the HTML is fully parsed
- Executes the script before the
DOMContentLoadedevent - Maintains execution order if multiple
deferscripts exist
The async Attribute
html<head>
<script src="analytics.js" async></script>
</head>With async, the browser:
- Downloads the script in parallel with HTML parsing
- Executes the script as soon as it finishes downloading (may interrupt parsing)
- Does NOT guarantee execution order between multiple
asyncscripts
Comparison Table
| Behavior | Default <script> | defer | async | type="module" |
|---|---|---|---|---|
| Blocks HTML parsing | Yes | No | No (but pauses briefly to execute) | No |
| Download timing | Sequential | Parallel | Parallel | Parallel |
| Execution timing | Immediately | After HTML fully parsed | As soon as downloaded | After HTML fully parsed |
| Execution order guaranteed | Yes | Yes | No | Yes (follows import graph) |
Can use document.write() | Yes | No | No | No |
| Best for | Legacy scripts | App logic, DOM-dependent code | Analytics, ads, independent scripts | Modern ES module code |
When to Use Each Strategy
html<!-- Best: defer for application code that needs the DOM -->
<script src="app.js" defer></script>
<!-- Good: async for independent third-party scripts -->
<script src="https://analytics.example.com/tracker.js" async></script>
<!-- Modern: type="module" for ES module code (deferred by default) -->
<script type="module" src="main.js"></script>
<!-- Avoid: bare script tags in the head (blocks rendering) -->
<!-- <script src="app.js"></script> DON'T do this in <head> -->What Happens Inside the Engine
Once the browser decides it is time to execute a script, it hands the source code to the JavaScript engine. Here is the internal pipeline:
- Tokenization: The source code text is split into tokens (keywords, identifiers, operators)
- Parsing: Tokens are organized into an Abstract Syntax Tree (AST)
- Bytecode generation: The AST is compiled into an intermediate bytecode format
- Execution: The bytecode interpreter runs the code, with JIT compilation optimizing hot paths
javascript// When the browser runs this script:
function updatePrice(basePrice, taxRate) {
const tax = basePrice * taxRate;
const total = basePrice + tax;
return total.toFixed(2);
}
const displayPrice = updatePrice(49.99, 0.08);
document.getElementById("price").textContent = `$${displayPrice}`;
// 1. Engine tokenizes: function, updatePrice, (, basePrice, ...
// 2. Engine parses into AST (function declaration + variable declarations)
// 3. Engine generates bytecode for each operation
// 4. Engine executes: calculates tax, updates the DOM elementThe Event Loop: Coordinating Execution
JavaScript in the browser is single-threaded, meaning only one piece of code runs at a time. Yet browsers handle animations, network requests, user clicks, and timers simultaneously. The event loop is the mechanism that makes this possible.
javascriptconsole.log("1: Script starts");
setTimeout(() => {
console.log("3: Timeout callback runs");
}, 0);
Promise.resolve().then(() => {
console.log("2: Promise callback runs");
});
console.log("4: Script ends");
// Output order:
// 1: Script starts
// 4: Script ends
// 2: Promise callback runs
// 3: Timeout callback runsEven though the setTimeout has a delay of 0 milliseconds, it does not run immediately. The event loop processes code in this order:
- Run all synchronous code in the current script (the "call stack")
- Process all microtasks (Promises,
queueMicrotask) - Process one macrotask (
setTimeout,setInterval, UI events) - Repeat
Single-Threaded Does Not Mean Slow
The browser itself is multi-threaded. Network requests, timers, and rendering happen on separate threads. When these operations complete, their callbacks are queued for the JavaScript thread to process via the event loop. JavaScript orchestrates; the browser parallelizes.
DOM Access: How Scripts Interact with the Page
The most common reason we write browser JavaScript is to read and modify the DOM (Document Object Model). The DOM is the browser's live, in-memory representation of the HTML document as a tree of objects.
javascript// Reading from the DOM
const heading = document.querySelector("h1");
console.log(heading.textContent); // Gets the text inside the <h1>
// Modifying the DOM
heading.textContent = "Updated Heading"; // Changes visible text
heading.style.color = "#FF4500"; // Changes text color
// Creating new elements and adding them
const paragraph = document.createElement("p");
paragraph.textContent = "This paragraph was created by JavaScript.";
document.body.appendChild(paragraph);Every time your script modifies the DOM, the browser may need to recalculate styles, recompute layout, and repaint the affected area. This is called a reflow (layout recalculation) or repaint (visual update).
Best Practices
Always use defer for application scripts. Unless you have a specific reason to block parsing, the defer attribute gives you parallel downloading and guaranteed execution after the HTML is fully parsed. This is the safest default for most projects.
Place scripts at the bottom of <body> as a fallback. If you cannot use defer or async (for example, with legacy code), placing <script> tags right before </body> achieves a similar effect because the HTML is already parsed by that point.
Batch DOM modifications together. Reading a DOM property and then immediately writing to the DOM repeatedly inside a loop forces the browser to recalculate layout on each iteration. Instead, read all values first, then write all changes in one batch.
Use requestAnimationFrame for visual updates. When animating elements or making frequent visual changes, wrap your DOM updates in requestAnimationFrame(). This tells the browser to execute your code right before the next paint, producing smoother animations at 60fps.
Minimize the size of scripts loaded in the critical path. Every kilobyte of JavaScript in the critical rendering path adds to the time-to-interactive. Use code splitting, tree shaking, and lazy loading to minimize the JavaScript that must run before the page becomes usable.
Common Mistakes and How to Avoid Them
These Mistakes Cause Real Performance Problems
Avoiding these errors will make your pages load faster and produce fewer bugs.
Accessing DOM elements before they exist. If your script runs in the <head> without defer, document.getElementById("app") returns null because the <head> is parsed before the <body>. Use defer, move scripts to the bottom of <body>, or wrap code in a DOMContentLoaded listener.
Using document.write() after the page loads. Calling document.write() after the initial HTML parse wipes the entire page and replaces it with whatever you pass. It only works safely during the initial parse, and even then it is considered an anti-pattern.
Loading too many synchronous scripts. Each regular <script> tag blocks parsing, so loading five large libraries sequentially in the <head> creates a waterfall of blocking requests. Use defer or bundle your scripts into a single file.
Triggering layout thrashing with alternating reads and writes. Repeatedly reading element.offsetHeight and then writing element.style.height inside a loop forces the browser to recalculate layout on every read because the write invalidated the previous layout.
Ignoring the difference between DOMContentLoaded and load. DOMContentLoaded fires when the HTML is fully parsed (but images and stylesheets may still be loading). load fires when everything, including images, is fully loaded. Use DOMContentLoaded for DOM manipulation scripts and load only when you need images to be available.
Next Steps
[Run JavaScript](/tutorials/programming-languages/javascript/how-to-run-javascript-in-the-browser-and-node) in different environments
Practice running the same JavaScript code in both the browser console and Node.js to understand how the same engine behaves in different runtime contexts.
Master Chrome DevTools for debugging
Learn how to use the Chrome DevTools console to test JavaScript snippets, inspect the DOM, and profile performance in real time.
Learn JavaScript variables and [data types](/tutorials/programming-languages/javascript/javascript-data-types-a-complete-beginner-guide)
Now that you know how the browser executes JavaScript, start building real programs by learning how to declare and use variables to store and manipulate data.
Explore DOM manipulation in depth
Go beyond the basics and learn how to select elements, handle events, and build dynamic interfaces using JavaScript DOM methods.
Rune AI
Key Insights
- Parser-blocking default: Regular
<script>tags pause HTML parsing until the script downloads and executes, so usedeferorasyncto avoid blocking - Defer for app code: The
deferattribute downloads scripts in parallel and executes them after parsing, preserving order and DOM availability - Event loop coordination: JavaScript is single-threaded, but the event loop and browser threads work together to handle async operations without blocking the UI
- DOM access timing: Scripts can only access DOM elements that have already been parsed, so placement and loading strategy directly affect what your code can see
- Batch DOM changes: Reading and writing to the DOM in alternating sequence triggers expensive layout recalculations; batch reads and writes separately for better performance
Frequently Asked Questions
Why does JavaScript block HTML parsing by default?
Should I always use defer instead of async?
What is the DOMContentLoaded event?
Can JavaScript access elements that haven't been parsed yet?
How do ES modules differ from regular scripts in the browser?
Does the browser compile JavaScript or interpret it?
Conclusion
Understanding how browsers load, parse, and execute JavaScript is foundational knowledge for building fast, reliable web applications. The critical rendering path, script loading strategies like defer and async, and the event loop all work together to determine when and how your code runs. By choosing the right loading strategy and being mindful of DOM interactions, you can avoid the most common performance pitfalls that slow down web pages.
More in this topic
OffscreenCanvas API in JS for UI Performance
Master the OffscreenCanvas API to offload rendering from the main thread. Covers worker-based 2D and WebGL rendering, animation loops inside workers, bitmap transfer, double buffering, chart rendering pipelines, image processing, and performance measurement strategies.
Advanced Web Workers for High Performance JS
Master Web Workers for truly parallel JavaScript execution. Covers dedicated and shared workers, structured cloning, transferable objects, SharedArrayBuffer with Atomics, worker pools, task scheduling, Comlink RPC patterns, module workers, and performance profiling strategies.
JavaScript Macros and Abstract Code Generation
Master JavaScript code generation techniques for compile-time and runtime metaprogramming. Covers AST manipulation, Babel plugin authorship, tagged template literals as macros, code generation pipelines, source-to-source transformation, compile-time evaluation, and safe eval alternatives.