From URL Entry to Render: A Deep Dive into Browser Internals for Interviews

Introduction

The author prepared for job interviews by summarizing the most frequently asked browser‑related questions encountered in about ten interviews, many of which focused on the end‑to‑end process from entering a URL to receiving a response.

Why URLs Need Parsing and Encoding

URLs must be encoded because the network standard allows only letters, digits, and a limited set of special characters. Unescaped characters can cause ambiguity, e.g., http://www.baidu.com?key=value where the key itself contains an equals sign.

The encoding rules follow UTF‑8; browsers use encodeURIComponent for parameters and encodeURI for the whole URL. The difference is that encodeURIComponent encodes a broader range of characters, making it suitable for query parameters.

DNS Resolution Process and Front‑End DNS Optimization

When a domain such as www.baidu.com is entered, the OS first checks the hosts file, then the local DNS cache, then the configured DNS resolver, and finally the root DNS servers if needed. Both recursive (non‑forwarding) and forwarding modes exist.

Front‑end DNS pre‑fetching can be enabled with:

<meta http-equiv="x-dns-prefetch-control" content="on" />
<link rel="dns-prefetch" href="http://bdimg.share.baidu.com" />

TCP Three‑Way Handshake

Client sends a SYN packet with an initial sequence number.

Server replies with SYN‑ACK, acknowledging the client’s sequence and providing its own.

Client sends an ACK, completing the connection.

Two‑way handshakes are insufficient because the server cannot be sure the client received the acknowledgment, leading to potential data loss.

From Network Card to Server (OSI Model Overview)

Data leaves the LAN, reaching a switch (ARP may be used to resolve MAC addresses).

The switch forwards the frame to a router, which operates at the network layer.

The router performs NAT, translating private IPs to public ones.

At the server, the transport layer (TCP) directs the packet to the appropriate service based on port numbers.

The application layer (HTTP/HTTPS) processes the request and generates a response.

Browser Caching Mechanisms

Strong cache : Controlled by Cache‑Control or Expires. If the resource is still fresh, the browser serves it from local storage without a network request.

Negotiated cache : The browser sends If‑None‑Match (ETag) and If‑Modified‑Since headers; the server replies with 304 Not Modified when the resource is unchanged.

Heuristic cache : When no explicit freshness information is present, browsers may compute freshness as 10% of the time difference between Date and Last‑Modified.

Cache lookup order:

1. Check memory cache; if found, load from memory.<br/>2. If not in memory, check disk cache; if found, load from disk.<br/>3. If not on disk, perform a network request.<br/>4. Store the fetched resource in both memory and disk caches.

Rendering Process

Parse HTML to build the DOM tree.

Parse CSS to build the CSSOM tree.

Execute JavaScript.

Combine DOM and CSSOM to create the render tree.

Layout: calculate the position of each node.

Painting: rasterize each node onto the screen.

Front‑End Rendering Optimizations

Keep HTML depth shallow (no more than six levels).

Place scripts at the end of the body or use async/defer.

Inline critical CSS for the first paint.

Simplify CSS selector hierarchy.

Minimize DOM manipulations and cache layout‑related values.

Prefer class toggling over direct style changes.

Animate only transform/opacity on positioned elements.

Pause animations when off‑screen.

Cache DOM queries and keep selectors simple.

Use DNS pre‑fetching for third‑party domains.

Performance Diagnosis

Use Chrome DevTools: the Network panel to inspect request/response details and the Performance panel to analyze rendering timelines, paint events, and scripting costs.