Interactive guide
HTTP request lifecycle
Every time you click a link, eight phases execute in sequence: DNS resolution, TCP handshake, TLS negotiation, request, server processing, response, parsing, and rendering. Step through each phase to understand what happens and how long it takes.
Request timeline
Phase 1 of 8
DNS Resolution
0-200 msThe browser resolves the domain name to an IP address. It checks the browser cache, OS cache, and then queries the configured recursive resolver. For frequently visited sites, this step is a cache hit taking under 1 ms.
Technical details
The browser calls getaddrinfo() (or equivalent), which may return a cached result or trigger a UDP/HTTPS query to the recursive resolver configured in the OS network settings.
The waterfall: where time goes
In browser DevTools (Network tab), each request shows a "waterfall" — a stacked bar chart of these phases. Understanding the waterfall tells you where to optimize:
Slow DNS? Use a fast public resolver (1.1.1.1), reduce TTLs wisely, or prefetch DNS for likely navigation targets with <link rel="dns-prefetch">.
Slow TCP/TLS? Use a CDN with edge nodes near your users. HTTP/3 (QUIC) combines TCP and TLS into a single round trip.
Slow server? Cache responses (CDN, Redis), use SSG for static pages, optimize database queries.
Slow rendering? Minimize render-blocking CSS and JS, lazy-load below-the-fold images, use font-display: swap for web fonts.
Frequently asked questions
How long does an HTTP request take?
A typical HTTPS request to a nearby CDN takes 50-200 ms total (DNS + TCP + TLS + server + transfer). Subsequent requests to the same server reuse the TCP/TLS connection, reducing latency to just the server processing and transfer time.
What is the difference between HTTP/1.1, HTTP/2, and HTTP/3?
HTTP/1.1 uses one request per TCP connection (or pipelining, which is rarely used). HTTP/2 multiplexes many requests over a single TCP connection using binary framing. HTTP/3 replaces TCP with QUIC (UDP-based) to eliminate head-of-line blocking and reduce connection setup to one round trip.
What is TTFB (Time to First Byte)?
TTFB measures the time from the browser sending the request to receiving the first byte of the response. It includes DNS, TCP, TLS, and server processing time. A good TTFB is under 200 ms for dynamic content and under 100 ms for static/CDN content.
Why do browsers limit concurrent connections?
HTTP/1.1 browsers limit concurrent connections per origin (typically 6). This prevents a single site from monopolizing network resources. HTTP/2 and HTTP/3 solve this with multiplexing — unlimited concurrent streams over a single connection.
What are Core Web Vitals?
Core Web Vitals are Google's metrics for user experience: LCP (Largest Contentful Paint — how quickly the main content loads), INP (Interaction to Next Paint — how quickly the page responds to input), and CLS (Cumulative Layout Shift — how much the layout moves unexpectedly).
Build and send HTTP requests
Test API endpoints with full control over method, headers, and body — directly from your browser with the destination disclosed first.
Open HTTP Request Builder