Inside the Browser: From URL to Render – A Complete Walkthrough

Preface

This article revisits a classic interview question about the complete browser request‑response cycle, providing a clearer, step‑by‑step explanation.

Note

The steps assume a simple HTTP request without HTTPS, HTTP/2, DNS complexities, proxies, or server issues.

Overall Process

URL parsing

DNS query

TCP connection

Processing request

Receiving response

Rendering page

1. URL Parsing

The browser first validates whether the input is a legal URL or a search keyword, performs auto‑completion, character encoding, and may enforce HSTS to upgrade to HTTPS. It also performs extra security checks and cache inspection.

2. DNS Query

The browser checks its own cache, then the OS cache, router cache, ISP DNS cache, and finally queries the root name server if needed. It distinguishes recursive and iterative queries, mentions DNS hijacking, and suggests front‑end dns‑prefetch optimization.

3. TCP Connection

TCP/IP is divided into four layers; each layer encapsulates data. The three‑way handshake establishes the connection before data transmission.

Application Layer – Send HTTP Request

The browser constructs an HTTP request containing headers (method, target, protocol) and an optional body; page loads use the GET method.

Transport Layer – TCP Segments

Data is split into segments, numbered, and sent after the three‑way handshake.

About TCP/IP three‑way handshake, many jokes and pictures illustrate it. Related topic: SYN flood attack.

Network Layer – IP Routing

Each packet includes source and destination IP addresses; ARP is used to resolve MAC addresses when the target is on a different network.

Note: In the OSI model ARP belongs to the link layer, but in TCP/IP it is considered part of the network layer.

Link Layer – Ethernet

Ethernet frames consist of a header (sender, receiver, type) and data. MAC addresses are unique to each network interface. Broadcast sends to all devices; unicast is the response.

Related topic: ARP attack.

4. Server Processing

Common HTTP servers (Apache, Nginx, IIS) listen for requests, spawn child processes, parse the HTTP request, verify virtual hosts, allowed methods, and user permissions. If a redirect is configured, a 301 response is sent. URL rewriting rules map real files or route to REST‑style URLs, after which the appropriate interpreter (e.g., PHP MVC) handles the request.

5. Browser Receives Response

The browser examines response headers, follows redirects, decompresses (e.g., gzip) if necessary, caches the resource, and parses it according to its MIME type (HTML, image, etc.).

6. Page Rendering

6.1 HTML Parsing

Parsing proceeds line by line and consists of four steps: decoding (convert bytes to characters), pre‑parsing (pre‑load resources such as img src), tokenization (lexical analysis into tokens like start tag, end tag, attribute name/value), and tree construction (building the DOM). The parser creates DOM nodes as soon as start tags are tokenized.

6.2 CSS Parsing

The CSS parser tokenizes according to the specification, builds a rule set, and matches selectors from right to left (e.g., div p {font-size:14px} matches p inside div). Using IDs and classes reduces selector complexity.

6.3 Rendering Tree

The DOM tree is merged with the CSS rule tree, ignoring nodes with display:none. The resulting rendering tree is used for layout.

6.4 Layout & Paint

Each node’s geometry (position, size) is calculated, then the paint() method draws the content.

6.5 Layer Merging

All painted layers are composited into a final bitmap.

6.6 Reflow & Repaint

Reflow recalculates layout when geometry changes (costly). Repaint updates visual appearance without layout changes (cheaper). For example, display:none triggers reflow, while visibility:hidden only triggers repaint.

6.7 JavaScript Compilation & Execution

Three phases: lexical analysis (tokenizing source code), pre‑compilation (creating execution contexts – global, function, eval – and building the scope chain), and execution (running bytecode). JavaScript runs on a single engine thread, while auxiliary threads handle events, timers, and asynchronous HTTP requests. Macro‑tasks (synchronous code, async callbacks) run after the current call stack; micro‑tasks (Promises, process.nextTick) run after macro‑tasks but before the next event loop tick.

console.log('1'); // macro task sync
setTimeout(function() {
    console.log('2'); // macro task async
});
new Promise(function(resolve) {
    console.log('3'); // macro task sync
    resolve();
}).then(function() {
    console.log('4'); // micro task
});
console.log('5'); // macro task sync

The output order is: 1, 3, 5, 4, 2.