Part of that gap is DNS. Before a browser can request anything from your domain, it has to turn that domain into an IP address. That lookup happens before the first byte of your page is even asked for. Once the answer is cached, the next visit skips the whole step.
DNS is one of the least discussed parts of web performance because it happens before any of the metrics people usually watch. It sits ahead of Time to First Byte, ahead of your server, ahead of your images.
It is also one of the easiest things to get quietly wrong, and we find problems here on a lot of the sites we are asked to speed up.
DNS is the system that translates a domain name into an IP address. When someone enters your domain, the browser asks a recursive resolver for the address. If that resolver does not already know, it works its way through the DNS hierarchy until it reaches the nameserver that holds your record, then returns the answer.
The important part for speed is that nothing else can start until this finishes. The browser cannot open a connection to an address it does not have yet.
Every separate domain your page touches needs its own lookup. Your site is one. Your font provider is another. Your analytics, your chat widget, and your video embed are three more. Each one is a fresh round trip the first time it is needed.
Enough to matter, and it varies a lot. MDN's performance documentation says plainly that DNS resolution can add significant latency to requests, and that for sites connecting to many third parties this latency can significantly reduce loading performance. The exact cost depends on the visitor's resolver, their network, and whether the answer is cached.
Vendors publish their own numbers. Cloudflare's launch post for the 1.1.1.1 resolver, written by Matthew Prince in April 2018, said DNSPerf ranked 1.1.1.1 as the fastest DNS resolver when querying non-Cloudflare customers, averaging around 14 milliseconds globally. That is a vendor claim about a resolver, not about your site.
The honest framing is that a single cached lookup is close to free and a cold lookup on a slow network is not. You cannot control which resolver your visitor uses, so the goal is to need fewer lookups rather than faster ones.
That reframing changes what you actually do. Most teams go looking for a faster DNS host. The bigger win is usually cutting the number of separate domains a page depends on.
TTL stands for time to live. It is a value on each DNS record that controls how long resolvers are allowed to cache the answer. Cloudflare's DNS documentation explains the trade-off directly. Longer TTLs speed up lookups because more results come from cache, but they also mean changes to your records take longer to reach people.
The default in Cloudflare is Auto, which works out to 300 seconds, or five minutes. For records that are not proxied, Cloudflare allows TTLs from 30 seconds on Enterprise plans, or 60 seconds otherwise, up to one day.
In normal operation, a longer TTL is the friendlier setting. Fewer visitors pay for a fresh lookup, and your records are not changing anyway.
The exception is the week around a launch or a move. We drop TTLs to a low value a day or two before a migration so that when the record changes, the world picks it up quickly. Then we put them back up once things are stable. Doing that backwards is how sites end up half-migrated for a day.
Because each new domain is a new lookup, and third-party tools bring domains with them. A single tag manager can pull in a chat widget, a heatmap tool, and two ad pixels, each on a different host. The browser has to resolve every one of them before it can fetch anything from them.
This is the version of the problem we see most often on client sites. The site itself is well built and the server responds quickly, but the page waits on a queue of unrelated hosts.
It compounds too. A third-party script often loads another script from a fourth domain, which means the second lookup cannot even begin until the first response arrives. That chain is invisible in most performance reports.
The fix is unglamorous. Audit what is on the page, remove what nobody reads, and self-host what you can. Our wider notes on how third-party scripts slow down your website cover the rest of that cost.
Both are resource hints you put in your HTML head. MDN describes dns-prefetch as a hint that the browser should resolve a domain name before the resource is requested. Preconnect goes further. MDN explains that preconnect establishes a connection, which includes DNS resolution plus the TCP connection and the TLS handshake on an HTTPS site.
So preconnect does more work up front and saves more time, which makes it the better choice for the one or two origins your page genuinely cannot render without. Think of your font host or the domain serving your hero image.
MDN also warns against overdoing it. If a page needs connections to many third-party domains, preconnecting all of them is counterproductive. It also notes that support for dns-prefetch is better than support for preconnect, so pairing the two is a reasonable pattern.
Two more details from the same documentation are worth knowing. Do not use dns-prefetch for your own domain, because that address is already resolved by the time the page is parsing. And if a browser does not support the hint, nothing breaks. We go through the full set of hints in our guide to preload, preconnect, and prefetch.
It matters more for reliability than for raw speed. Your authoritative DNS provider answers on your behalf, and if it is slow or unreachable in some regions, visitors there wait longer or fail entirely. Providers using Anycast routing answer from the location nearest the visitor, which evens out the difference.
DNSPerf, which publishes ongoing DNS benchmarks, says it tests all providers every minute from more than 200 locations globally, over IPv4 with a one second timeout, and updates its public data hourly. That is the kind of measurement worth checking before you switch.
What we would not do is chase small differences between reputable providers. The gap between a good global provider and a slightly better one is not where your page speed problem lives.
The gap that does matter is between a global provider and a single-region nameserver bundled free with a cheap hosting plan. If your visitors are worldwide and your DNS is not, that shows up.
It decides how long you live in two worlds at once. When you point a domain at a new host, resolvers keep serving the old answer until the cached record expires. Some visitors hit the new site immediately and some keep landing on the old one, for as long as your TTL allows.
That is why we treat DNS as part of the launch plan rather than the last click. Lower the TTL ahead of time, verify the new host answers correctly on its own address first, then change the record, then watch both.
The related mistake is switching DNS before the new site is genuinely ready, which turns a controlled cutover into a public test. Keeping the old site reachable until the new one is verified is what makes a rollback possible.
Redirects and DNS get confused with each other constantly, and they solve different problems. DNS decides which server answers your domain. Redirects decide what that server says about a specific URL. Getting one right does not save you from getting the other wrong.
Open the network panel in Chrome DevTools and look at the timing breakdown for the first request. The DNS lookup segment is listed separately from the connection and the response. If that segment is consistently large across visitors and locations, DNS is worth attention. If it is small and your server response is large, your problem is elsewhere.
Test from more than one place. DNS results are highly local, so a fast lookup from your own office says very little about a visitor on another continent.
Watch for the pattern rather than a single number. One slow cold lookup is normal. A page that spends time resolving six domains before it can paint anything is a structural issue.
If your first request is fine but the page still feels slow to start, the problem is more likely on the server side, which is the territory our guide to Time to First Byte covers.
Start by counting domains, not by switching providers. Open your page, list every distinct host it requests, and remove or self-host the ones that do not earn their place. Then add preconnect for the one or two origins that are genuinely critical, and leave the rest alone.
After that, check your TTLs are sensible for normal operation and write the migration steps down somewhere before you need them. Those two habits cover most of the DNS pain we see.
The deeper point is that DNS rewards subtraction. There is no setting that makes a lookup free, but there is always a way to need fewer of them.
If you want us to look at where your site spends its first few hundred milliseconds, or you have a domain move coming up and want a second pair of eyes on the plan, we are happy to walk through it. Reach out at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.