DNS and Web Performance

DNS is the gate that opens before anything loads

DNS resolution is the first step in every network connection. Before a browser can establish a TCP connection, negotiate TLS, and send an HTTP request, it must resolve the hostname to an IP address. DNS latency directly gates the metrics that define user experience.

Time to First Byte (TTFB)

TTFB = DNS Lookup + TCP Handshake + TLS Handshake + Server Processing + First Byte Transit

DNS typically contributes 10–30% of TTFB on a cache miss, or under 5% on a cache hit. Since nothing renders until the first byte arrives, slow DNS disproportionately affects perceived performance.

First Contentful Paint (FCP)

FCP includes TTFB entirely. A 200 ms DNS delay pushes FCP by at least 200 ms — directly perceptible to users. A “good” FCP is under 1.8 seconds.

Largest Contentful Paint (LCP)

LCP — the Core Web Vital for loading performance — is affected when the LCP resource (typically a hero image) is served from a different domain (a CDN or image service) that requires its own DNS resolution.

The revenue connection

The relationship between latency and revenue is well-documented:

Company	Finding	Year
Amazon	Every 100 ms of added latency cost 1% in sales	2006
Google	500 ms extra in search page generation dropped traffic by 20%	2006
Bing	2 second slowdown: revenue per user down 4.3%	2009
Walmart	100 ms improvement = +1% incremental revenue	2012
Akamai	100 ms delay = 7% drop in conversion rate	2017

On a cold cache, DNS contributes 100–400 ms to total load time. Given that 100 ms costs 1% of sales for Amazon, a 300 ms DNS resolution could theoretically cost up to 3% of sales for affected users.

A single page triggers dozens of DNS lookups

Modern web pages load resources from many different domains. Each unique domain requires its own DNS resolution. Over 90% of web pages include one or more third parties.

Website type	Typical unique domains	Key third parties
Simple blog	5–10	Google Fonts, Analytics, maybe an ad network
News site	30–60	Ads, analytics, social widgets, CDNs, video players
E-commerce	20–40	Payment processors, analytics, recommendation engines
Content-heavy media	50–150+	Multiple ad exchanges, trackers, video CDNs, social embeds

A study of The Toast (a media site) found it loaded resources from 143 different domains, generating 391 HTTP requests. Each of those 143 domains required its own DNS resolution.

Where the domains come from

A typical news site’s DNS lookups break down like this:

Category	Domains	Examples
First-party content	2–5	www.site.com, static.site.com, api.site.com
CDN delivery	2–4	cdn.cloudflare.com, d1234.cloudfront.net
Advertising	10–25	doubleclick.net, googlesyndication.com
Analytics	3–8	google-analytics.com, segment.io, hotjar.com
Social widgets	3–5	platform.twitter.com, connect.facebook.net
Fonts/styling	1–3	fonts.googleapis.com, use.typekit.net
Video	2–5	youtube.com, vimeo.com

Every one of those domains is a DNS lookup that must complete before the resource can load. Third-party domains are especially expensive because the browser has no prior connection to them — every lookup is cold.

Browser resource hints: resolving DNS before you need it

Browsers provide mechanisms to resolve DNS ahead of time, eliminating DNS latency from the critical rendering path.

dns-prefetch

<link rel="dns-prefetch" href="//cdn.example.com">

Performs DNS resolution only (no TCP/TLS). Saves 20–120 ms per domain. Very low cost — safe to use broadly. Supported in all modern browsers.

preconnect

<link rel="preconnect" href="https://cdn.example.com">

Performs DNS + TCP + TLS handshake. Saves 100–500 ms per connection. Higher cost: each preconnect holds a socket open. Best limited to 2–4 most critical third-party origins.

preload

<link rel="preload" href="https://cdn.example.com/hero.jpg" as="image">

Downloads the resource immediately. Most aggressive: includes DNS + TCP + TLS + full download. Use only for resources needed in the current page’s critical path.

The best practice hierarchy

1. preconnect for the 2–4 most critical third-party origins
2. dns-prefetch for remaining known third-party domains
3. preload for specific critical resources

The key insight is that dns-prefetch has almost no downside — it is a speculative DNS resolution that costs a single UDP packet. If the domain is used, you save the lookup time. If it is not used, you wasted nothing meaningful.

HTTP/2 and HTTP/3 connection coalescing

HTTP/2 and HTTP/3 introduce connection coalescing, which allows a single connection to serve multiple hostnames if:

1. The hostnames resolve to the same IP address
2. The TLS certificate covers all the hostnames (via SAN or wildcard)
3. The ALPN negotiation matches

Scenario	DNS queries	Connections
HTTP/1.1 with 5 subdomains	5 DNS + 5 TCP/TLS	5 separate connections
HTTP/2 with 5 subdomains (same cert, same IP)	5 DNS but 1 TCP/TLS	1 coalesced connection
HTTP/2 with 5 subdomains (different IPs)	5 DNS + 5 TCP/TLS	5 separate connections

Connection coalescing does not reduce the number of DNS queries — the browser must still resolve each hostname. But it dramatically reduces the TCP+TLS handshake overhead, saving 1–3 RTTs per coalesced connection. A single preconnect to the primary origin may be sufficient when subdomains coalesce onto the same connection.

The compounding effect

DNS latency compounds across a page load. If a news site loads resources from 40 domains and the browser can resolve 6 DNS queries in parallel (a common browser limit), that is 7 rounds of DNS resolution. Even at 30 ms per resolution (warm cache), that is 210 ms of DNS time alone — before any TCP connections, TLS handshakes, or HTTP requests begin.

This is why the combination of warm resolver caches, dns-prefetch hints, and reducing third-party domain count is the most effective DNS performance strategy for web applications. Each technique addresses a different part of the problem: caches reduce per-lookup time, prefetch hints hide the latency, and domain reduction eliminates lookups entirely.