What Really Happens When You Type a URL? From DNS to Rendering Explained
This article walks through the complete lifecycle of a browser request—URL parsing, DNS lookup, TCP handshake, OSI‑layer transmission, caching strategies, HTML rendering, and performance optimizations—mirroring real interview questions faced by front‑end engineers.
Preface
When preparing for a job change, I collected the most frequently asked interview questions about browsers, which appeared in about six out of ten interviews at large and medium companies. The following is a comprehensive, slightly dramatized recount of those questions.
Question: What happens from entering a URL in the address bar to receiving a response?
I started by saying the URL is first parsed and the DNS system is used to look up the IP address.
Why does a URL need parsing and what are the DNS query rules?
URLs must be encoded because the network standard allows only letters, digits, and a limited set of special characters. Without encoding, characters like = in query strings cause ambiguity. For example, http://www.baidu.com?key=value becomes ambiguous if the key itself contains = (e.g., ke=y=value).
The encoding rule is UTF‑8.
All browsers use UTF‑8; other encodings such as GB2312 are not used for URLs. To ensure UTF‑8, encodeURIComponent can be applied. encodeURIComponent encodes a broader range of characters than encodeURI; the former is suitable for query parameters, the latter for the whole URL.
Explain the DNS resolution process and how to optimize DNS in HTML.
The DNS lookup proceeds as follows:
The OS first checks the hosts file for a matching entry.
If not found, it checks the local DNS resolver cache.
If still missing, it queries the configured DNS server.
If the server has no cached answer, it queries the root DNS servers, then the authoritative servers for the domain, until the final IP address is obtained. This is the non‑forwarding mode.
Front‑end DNS optimization can be done by adding DNS prefetch directives in the HTML head:
<meta http-equiv="x-dns-prefetch-control" content="on" />
<link rel="dns-prefetch" href="http://bdimg.share.baidu.com" />After the IP is resolved, the TCP three‑way handshake occurs.
Why is a three‑way handshake required instead of a two‑way handshake?
First handshake: Host A sends a SYN packet with an initial sequence number.
Second handshake: Host B replies with SYN‑ACK, acknowledging A's sequence and providing its own.
Third handshake: Host A sends an ACK, confirming B's sequence, establishing a reliable connection.
A two‑way handshake would leave Host B unable to confirm that Host A received its acknowledgment, making the connection vulnerable.
Bonus question: From the network card to the server, what happens according to the OSI model?
Data is sent from the LAN to the switch; if the switch lacks a MAC‑IP mapping, it uses ARP.
The switch forwards the frame to the router, which operates at the data link and network layers.
The router performs NAT, translating the internal IP to a public one, and forwards the packet toward the server.
On the server, the transport layer (TCP) uses the port number to dispatch the data to the appropriate service.
The application layer (HTTP/HTTPS) processes the request and returns a response.
Page Rendering Optimization
Keep HTML structure shallow (no more than six levels).
Place scripts at the end of the body when possible.
Inline critical CSS for the first paint.
Simplify CSS selector hierarchy.
Minimize DOM operations and cache style information to avoid layout thrashing.
Prefer class toggling over direct style changes in JavaScript.
Animate only elements with absolute or fixed positioning.
Pause animations when the page is off‑screen or scrolling.
Cache DOM queries and keep selectors simple.
Enable DNS pre‑resolution for resources hosted on multiple domains.
Performance diagnosis can be done with Chrome DevTools: the Network panel for request details and the Performance panel for rendering timelines.
Cache handling details:
On first load, the server returns a 200 response and the browser caches the body along with response headers (e.g., Date).
On subsequent loads, strong cache directives ( Cache‑Control, Expires) are evaluated first. If the resource is fresh, it is served from cache without a network request.
If stale, the browser performs a conditional request with If‑None‑Match (ETag) and If‑Modified‑Since. A matching ETag results in a 304 Not Modified response.
If the response lacks explicit freshness information, browsers may apply heuristic caching, typically using 10 % of the time difference between Date and Last‑Modified as the freshness lifetime.
1、Check memory cache; if present, load from memory.
2、If not in memory, check disk cache; if present, load from disk.
3、If not cached, perform a network request.
4、Store the fetched resource in both memory and disk caches.Heuristic cache example:
// Calculate freshness as 10% of (Date - Last‑Modified)
response_is_fresh = max(0, (Date - Last‑Modified)) % 10;After the HTML is received, the browser parses it to build the DOM tree, constructs the CSSOM tree, executes JavaScript, builds the render tree, performs layout, and finally paints the pixels on the screen.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
