DNS speed: how name lookups affect your site

How a lookup works

The Domain Name System, DNS, is the system that maps a human-friendly domain name such as example.com to the numeric address of a server. Finding that address is called a DNS lookup.

MDN describes the path of a lookup like this. The browser first asks the computer whether it already knows the address, using a local DNS cache. If it does, the lookup ends there and costs next to nothing. If not, the computer asks a DNS server, whose job is to say which address belongs to each registered domain. That server may have the answer in its own memory, and if it does not, it asks other servers, ending at the authoritative name servers that hold the official records for the domain.

Every layer keeps what it learns for a while. Each DNS server that knows about a domain stores the information for some time before it is discarded and fetched again. That time is the TTL, the "time to live" in seconds that comes with every record.

So a lookup has two very different speeds. When a cache has the answer, it is fast. When nobody has it, the question travels further. That is why the first visit to a site, or the first visit after the cached answer has expired, can be slower than the second.

Where the time goes

DNS is the first step in the chain of connection setup. It is described, with TCP and TLS, in connection setup. It also counts as part of the time to first byte that a visitor experiences.

MDN's latency guide notes that the greater the number of host names a page uses, the more lookups are needed. A page that loads files from ten different names asks ten questions.

How slow can it be? In the 2025 Web Almanac, HTTP Archive's lab tests measured the median DNS lookup for names served by CDNs at 176 milliseconds on mobile and 52 on desktop. For names that were not on a CDN it was 217 and 129. The Almanac credits the CDNs' wide networks of servers, their use of anycast routing and their tuned DNS systems. These are measurements from a controlled data center, so treat them as a sign of how much a good provider can matter, not as numbers you will see.

What you can control

1. Use fewer host names. Every distinct name needs a lookup, including subdomains such as images.example.com and every third-party service. The cheapest lookup is the one you do not make. Serve fonts and scripts from your own name when you can, and remove tags that nobody uses. See third-party scripts.

2. Link to the final address. A redirect from example.com to www.example.com can mean a lookup for a second name, a connection and a round trip before the page even starts. Pick one name, and use it in every link, sitemap and ad.

3. Keep your records with a fast provider. When caches have no answer, the question reaches the authoritative servers for your domain. A provider with servers in many places answers faster than one with a single location. CDN companies run DNS networks of their own, and the Almanac figures above suggest that names behind them resolve faster. Moving DNS hosting is a change worth planning, because a mistake can make the whole site unreachable.

4. Set a TTL that fits. A short TTL lets a change reach everyone quickly but makes the caches forget the answer sooner, so more visitors wait for a fresh lookup. A long TTL means fewer lookups but a slower rollout of changes. A reasonable approach is a long TTL for records that rarely change, with a planned drop before a move. Remember that a cache holding the old answer keeps it until the old TTL runs out, so lower the TTL a full old TTL ahead of the change.

5. Keep chains of aliases short. A CNAME record says that one name is an alias of another. CDNs use them to steer visitors to a nearby server. Each alias in a chain is another name to resolve when nothing is cached, so avoid chains of several aliases when one will do.

6. Use the newer records where your provider supports them. The 2024 Web Almanac explains that DNS can carry more than addresses. SVCB and HTTPS records can tell a browser which protocols a site supports, such as HTTP/3, before the first connection. Support differs between providers. See HTTP/2 and HTTP/3.

7. Warn the browser early about the hosts you must use. dns-prefetch resolves a name ahead of time, and MDN describes it as a way to mask the latency. preconnect does the lookup and the connection. web.dev says that early connections to important third-party origins can save 100 to 500 milliseconds. Use them for the few origins the first screen needs; the resource hints guide has the code and the limits.

How to measure DNS time

• Chrome DevTools. Click a request in the Network panel and open the Timing tab. The phase called DNS Lookup shows the time the browser spent resolving the name. Requests to a host the browser has already used usually show none.
• The command line. curl can print the time from the start until the name was resolved:

curl -o /dev/null -s -w 'dns lookup: %{time_namelookup}s\n' https://example.com/

The result depends on what your computer and its DNS server had cached, so run it a few times and from different networks. The first run is the one that looks like a first-time visitor.

• Count the names. Add the Domain column in the Network panel and count the different names. Every one is a lookup for a visitor whose caches are empty.

What can go wrong

• A very short TTL left behind after a migration, so visitors keep waiting for fresh lookups.
• A forgotten record pointing to an old server, after the site moved, which can send some visitors to the wrong place.
• A single DNS server. If the servers for your domain do not answer, new visitors whose DNS servers have nothing cached cannot find your site at all. Ask your provider about redundancy.
• Testing from one place. Lookup speed varies by location and by network. A test from your office says little about visitors elsewhere.

Check your own page

Run the free audit and count how many different hosts the page uses in the request list. If the first byte is slow for visitors far from your server, look at your DNS provider as well as your hosting. For the rest of the setup steps, see connection setup.

Sources

• DNS and TTL in the MDN glossary, and What is a domain name? on MDN: how a lookup works and how records are cached.
• Understanding latency and Using dns-prefetch on MDN.
• Establish network connections early on web.dev.
• CDN chapter, Web Almanac 2025 and HTTP chapter, Web Almanac 2024: DNS timings and HTTPS records.