The Complete Journey
Step 1 — DNS Lookup
Before the browser can connect to a server, it needs its IP address. The browser checks its DNS cache first, then the OS cache, then queries the configured DNS resolver (e.g. 8.8.8.8). If not cached, the resolver queries root nameservers → TLD nameservers → authoritative nameserver to get the IP.
This can take 10–100ms for an uncached lookup. Subsequent lookups for the same domain are instant (cached).
Step 2 — TCP Connection
With the IP address, the browser opens a TCP connection via a 3-way handshake: SYN → SYN-ACK → ACK. This takes one round trip (RTT). For nearby servers: ~1ms. For cross-continental: ~150ms. HTTP/2 and HTTP/3 reuse connections — the handshake cost is paid once, then subsequent requests reuse the connection.
Step 3 — TLS Handshake (HTTPS only)
For HTTPS, the browser negotiates encryption: exchanges cipher suites, validates the server's TLS certificate, and derives a shared session key. TLS 1.3 completes this in one additional round trip. This is the TLS overhead you see as "ssl" time in browser DevTools Network tab.
Step 4 — HTTP Request and Response
The browser sends an HTTP GET request for the URL. The server processes it and sends back an HTTP response with status code (200 OK) and the HTML body. The first byte received is measured as TTFB (Time to First Byte).
Step 5 — HTML Parsing and DOM Construction
As HTML bytes arrive, the browser's HTML parser converts them into tokens (start tags, end tags, text) and then builds the DOM tree. The DOM is a hierarchical tree of nodes — every HTML element is a node. This is incremental — the browser does not wait for all HTML to arrive before starting.
When the parser encounters a <script> tag (without async/defer), it stops parsing and executes the script before continuing — because the script might call document.write() and modify the HTML being parsed.
Step 6 — CSS Parsing and CSSOM
When the parser encounters a <link rel="stylesheet">, it fetches the CSS file. Parsing CSS builds the CSSOM (CSS Object Model) — a tree of CSS rules mapped to DOM nodes. The browser cannot render anything until the CSSOM is complete, because styles affect the layout of every element.
Step 7 — Render Tree Construction
The browser combines the DOM and CSSOM to build the Render Tree — only visible elements are included. Nodes with display: none are excluded. Each Render Tree node contains the visual properties needed to display it.
Step 8 — Layout (Reflow)
The browser calculates the exact position and size of every element in the Render Tree. This is computed from the top of the document downward, calculating each element's width, height, and coordinates. This is also called "reflow" when it happens after the page loads.
Step 9 — Paint
The browser draws pixels for each node — backgrounds, borders, text, images, shadows. Modern browsers paint different visual layers separately for compositing efficiency.
Step 10 — Compositing
Layers are composited into the final image and displayed on screen. Hardware-accelerated properties (transform, opacity) are composited on the GPU, making animations smooth without triggering layout or paint.
async vs defer vs default scripts
| Script type | Download | Execution | DOM ready? |
|---|---|---|---|
| <script src="..."> | Blocks HTML parsing | Immediately after download | No |
| <script async> | Parallel with parsing | As soon as downloaded | Maybe |
| <script defer> | Parallel with parsing | After HTML fully parsed | Yes |
Performance Optimisations
- Reduce DNS lookups: Use fewer third-party domains; add DNS prefetch hints
- Use HTTP/2: Multiplexes multiple requests over one connection
- Use a CDN: Reduces geographic RTT — serves from edge nodes closer to users
- Inline critical CSS: Put above-the-fold CSS directly in
<head>to avoid a render-blocking request - Defer non-critical JS: Add
deferor move scripts to end of<body> - Avoid forced synchronous layouts: Do not read layout properties (offsetHeight) then write to the DOM in a loop
- Use transform/opacity for animations: These skip layout and paint; handled by GPU compositor
💡 Use Chrome DevTools to See This in Action
Open DevTools → Performance tab → Record → reload page. You will see the exact timeline of DNS, TCP, TLS, Request, Response, Parse HTML, Evaluate Script, Style, Layout, Paint, and Composite — each step visualised with timing.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — How Browsers Work
The main steps are: (1) DNS lookup — resolve domain to IP. (2) TCP connection — establish connection to server. (3) TLS handshake — negotiate encryption (for HTTPS). (4) HTTP request/response — browser requests the HTML, server responds. (5) HTML parsing — browser builds the DOM tree. (6) CSS parsing — browser builds the CSSOM tree. (7) Render tree construction — combine DOM and CSSOM. (8) Layout — calculate positions and sizes. (9) Paint — draw pixels. (10) Compositing — layer-by-layer final output.
The DOM (Document Object Model) is the browser's in-memory representation of an HTML document as a tree of objects. Each HTML element becomes a node. JavaScript can read and modify the DOM — adding nodes, changing text, toggling classes. The DOM is not the same as the HTML source — it is a live tree that changes as JavaScript runs and the page is interactive.
Render-blocking resources prevent the browser from displaying content until they are downloaded and processed. CSS files in <head> are render-blocking — the browser must build the CSSOM before rendering. JavaScript files are also render-blocking by default because JS can modify the DOM. Fix: use async or defer on script tags, inline critical CSS, and lazy-load non-critical resources.
Both async and defer load scripts without blocking HTML parsing. async: the script executes as soon as it downloads, potentially before the DOM is ready — use for independent scripts like analytics. defer: the script executes after the HTML is fully parsed, in document order — use for scripts that need the DOM or must run in sequence. defer is usually the right choice for most scripts.
Reflow (layout) happens when the browser recalculates the geometry of elements — their size and position. Triggered by: adding/removing DOM nodes, changing dimensions, font size changes. It is expensive because it may affect the entire page. Repaint happens when visual appearance changes without geometry changes — color, background, visibility. Less expensive than reflow but still costly. Avoid frequent DOM changes in JavaScript loops; batch updates or use a virtual DOM framework.
The critical rendering path is the sequence of steps the browser must complete before displaying anything on screen: parse HTML → build DOM → fetch CSS → build CSSOM → build Render Tree → Layout → Paint. Optimising the critical rendering path is the core of web performance. Techniques: minimise render-blocking resources, reduce critical CSS, preload key resources, inline critical CSS in <head>.