Q253: Browser Request Lifecycle DNS TCP TLS and HTTP Versions

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain what happens before a response starts arriving.

Many frontend engineers jump directly from URL to HTML.

Senior engineers understand DNS, connection setup, TLS, HTTP versions, connection reuse, prioritization, and how those details show up in performance debugging.

Short Interview Answer

Before the browser receives a response, it resolves the hostname with DNS, opens or reuses a connection, negotiates TLS for HTTPS, sends the HTTP request, and waits for the server or CDN to respond. HTTP/1.1, HTTP/2, and HTTP/3 differ in connection behavior, multiplexing, and head-of-line blocking. For frontend performance, this matters because DNS lookup, connection setup, TLS negotiation, redirects, slow TTFB, and poor connection reuse can delay HTML, API responses, and LCP resources.

Detailed Interview Answer

The browser request lifecycle is the hidden beginning of page speed.

A page can have excellent React code and still feel slow if the network path is inefficient.

The lifecycle usually includes:

URL parsing
cache lookup
DNS resolution
connection setup
TLS negotiation
HTTP request
server or edge processing
response transfer
browser parsing

Some steps can be skipped through caching or connection reuse.

Some steps can be made faster through preconnect, DNS prefetch, CDN placement, and avoiding redirect chains.

DNS Resolution

DNS maps a hostname to an IP address.

Example:

learning-studio.krishnadevashish.com -> edge server IP

DNS can involve:

browser DNS cache
OS DNS cache
recursive resolver
authoritative nameserver
CDN routing

DNS cost is visible in DevTools timing when a new hostname is used.

Too many third-party origins can create extra DNS and connection work.

TCP Connection

For HTTP/1.1 and HTTP/2 over TLS, the browser usually needs a TCP connection.

TCP setup requires a handshake.

This adds latency before the request can be sent.

Connection reuse helps avoid repeated handshakes.

That is why spreading critical assets across many origins can be expensive.

TLS Negotiation

HTTPS requires TLS.

TLS provides:

encryption
server identity
data integrity
protection against passive network observers

TLS negotiation adds work, but modern TLS and connection reuse reduce the cost.

Still, for a cold page load on a high-latency network, DNS plus TCP plus TLS can be visible.

HTTP/1.1

HTTP/1.1 can reuse connections, but it has limits.

Historically, browsers opened several connections per origin to parallelize requests.

Problems include:

request queuing
limited parallelism
head-of-line blocking per connection
extra connection overhead

This is why old frontend advice favored domain sharding.

That advice is often harmful with HTTP/2 and HTTP/3.

HTTP/2

HTTP/2 supports multiplexing many streams over one connection.

Benefits include:

fewer connections
parallel requests on one connection
header compression
better reuse for same-origin assets

But HTTP/2 still runs over TCP.

TCP packet loss can still affect streams on the same connection.

Frontend teams should avoid assuming HTTP/2 removes all waterfall problems.

Discovery order and resource priority still matter.

HTTP/3

HTTP/3 runs over QUIC, which is built on UDP.

It is designed to improve connection setup and reduce transport-level head-of-line blocking.

Potential benefits:

faster connection establishment
better behavior on lossy networks
connection migration
reduced head-of-line blocking

Frontend engineers usually do not implement HTTP/3 directly.

But they should understand that hosting, CDN, and browser support can change real user performance.

Redirect Chains

Redirects can force repeated network steps.

Example:

http://site.com
-> https://site.com
-> https://www.site.com
-> https://www.site.com/home

Each redirect delays the final document.

For LCP-heavy pages, this can be costly.

Prefer one canonical URL and direct navigation.

Connection Reuse

Connection reuse is important for performance.

The browser may reuse existing connections when:

scheme matches
host matches
certificate allows it
protocol allows it
connection is still open
network conditions permit it

preconnect can help when a critical third-party origin is definitely needed soon.

Use it sparingly.

Every preconnect consumes resources.

Resource Discovery

Even after connection setup, the browser cannot request what it has not discovered.

Critical resources may be discovered from:

HTML parser
CSS files
JavaScript execution
preload hints
module graph
server-rendered markup

If the LCP image is hidden behind JavaScript, the network may be idle while the browser waits to discover it.

That is a frontend architecture problem, not only a server problem.

DevTools Timing

Network timing can show:

queueing
stalled
DNS lookup
initial connection
SSL
request sent
waiting for server response
content download

Senior engineers read these timings before guessing.

If DNS and connection time dominate, code splitting may not help.

If waiting for server response dominates, TTFB and backend or edge behavior need attention.

If content download dominates, compression and payload size matter.

Interview Example

If asked, "Why is the first page load slow but refresh is fast?"

You can answer:

warm DNS cache
warm TLS session
reused connection
browser cached assets
CDN cache warmed
framework data cache warmed
service worker cache populated

Then propose measuring cold and warm loads separately.

Common Mistakes

Common mistakes include:

ignoring DNS and TLS in performance reviews
using too many third-party origins
adding preconnect to every vendor
assuming HTTP/2 removes all prioritization problems
leaving redirect chains unresolved
debugging bundle size before checking TTFB
forgetting mobile networks magnify round trips

Senior-Level Framing

The senior framing:

"I separate network setup, server response, transfer, parsing, and rendering. That prevents me from optimizing the wrong layer. If the slow part is DNS, TLS, redirects, or TTFB, changing React components will not solve the root cause."

Practice Prompt

Record a cold load and a warm load for the same page.

Compare:

DNS time
connection time
TLS time
TTFB
download size
cache status
number of origins
redirect count
LCP discovery time

Explain which parts improved and why.

Final Mental Model

Before frontend code runs, the browser has already done a lot of work.

Understanding that work helps you debug performance as a system, not as a collection of isolated JavaScript files.