You opened a waterfall chart for your homepage and the very first bar starts with a coloured segment labelled DNS. On some test runs it is barely visible. On others it is long enough to notice, and further down the chart the same coloured slice appears again for fonts, analytics and a chat widget. A slow DNS lookup is not something most site owners think about, because nothing on the website itself controls it.
That is exactly why it is worth understanding. DNS sits at the very start of every visit, before the server is contacted at all, and it is set up in a different place from your hosting: often at the registrar where you bought the domain, sometimes years ago. This post explains where DNS fits in the load, what makes it slow, how to see the time it takes, and what you can change.
Where DNS sits in the chain
When someone types your address or taps a link, their device knows the name, not where the server is. Before anything else happens it has to translate the name into an IP address. That translation is the DNS lookup. Only after it finishes can the browser open a connection, negotiate encryption and ask for the page.
So the order for a first visit is roughly:
- DNS lookup: find the IP address for the domain.
- Connection: open a connection to that address.
- Encryption: agree the secure connection for HTTPS.
- Request and wait: ask for the page and wait for the server.
- Download: receive the HTML, then repeat steps 1 to 4 for any new domains the page uses.
Everything later in the visit waits for step one. If the lookup is slow, the whole page starts late, and no amount of caching on the server can make up for it. If you want the difference between the domain, the DNS and the hosting spelled out, our post on how a domain and hosting differ covers that.
Why most lookups are quick, and when you get a slow DNS lookup
Answers are cached at several levels: in the browser, in the device’s operating system, and at the resolver, which is usually run by the visitor’s internet provider or a public DNS service. Once one of those has a fresh answer, later visitors using it get the address almost instantly.
A lookup becomes slow when none of those caches has the answer. Then the resolver has to ask your domain’s authoritative nameservers, the servers that hold the real records. How quickly those respond, and how far away they are from the resolver, decides how long the visitor waits.
That happens more often than you might expect:
- The first visit from a resolver that has not seen your domain recently.
- After the cached answer expires, which is controlled by the TTL on your records.
- For every third-party domain the page uses that this visitor has not looked up lately.
DNS and website speed: what makes lookups slow
Slow or distant nameservers
Free DNS that comes with a domain registration is often perfectly adequate. Sometimes it is run from a small number of locations, far from much of your audience, or it simply answers slowly. Managed DNS services from larger networks usually have servers in many regions, so resolvers around the world get an answer from somewhere nearby.
Very short TTLs
TTL, time to live, tells resolvers how long they may keep an answer before asking again. A short TTL means answers expire sooner, so more visitors pay for a full lookup. Short TTLs are useful during a migration, when you want changes to spread quickly. Left in place permanently, they cost a little speed for no benefit.
Chains of aliases
A CNAME record points one name at another. If www points to a name that itself points to another name, the resolver has to follow each step. Some setups for site builders, CDNs or email services create several links in a chain. Each one can add time on an uncached lookup.
Too many domains on the page
Every separate domain a page loads from needs its own lookup: your own site, maybe a subdomain for images, Google Fonts, an analytics service, a tag manager, an ad pixel, a review widget, a chat service, a video host. A few are fine. A page that calls out to a dozen different domains spends real time just on lookups, and you control none of their nameservers. Our post on external scripts that slow a page deals with trimming those.
How to see DNS time
In a waterfall chart
WebPageTest and GTmetrix both show DNS as its own coloured segment at the start of each request to a new domain. Look at the first row for your own domain, then scan for other rows with a DNS segment; each is a domain the browser had to look up. Our guide to reading a waterfall chart explains the other segments and colours.
Run the test more than once. The first run often includes a full lookup and later runs may not, which tells you how much of the delay comes from cache misses.
In Chrome’s developer tools
Open the Network tab, reload, click the first request and open Timing. The “DNS Lookup” line shows how long it took for that load. Your own browser has probably cached your domain already, so this is better for checking third-party domains on a fresh profile than for measuring your own.
From a terminal
dig yourdomain.com prints the answer and a “Query time” line. Running it against different public resolvers shows how they see your domain. The same output shows the TTL on each record, which is often the most useful single fact you will get.
What you can change
Know where your DNS is hosted
Look up your domain’s nameservers. They tell you who answers for your domain: the registrar, the host, a CDN or a separate DNS service. Many owners are surprised, especially when the site was set up by someone else. Write it down along with the login, in the business’s name.
Consider managed DNS if the current provider is slow
If tests from several locations show slow or inconsistent answers from your nameservers, moving DNS to a provider with a wide network is a reasonable step. It is a careful job: every record must be copied exactly, including email records (MX, SPF, DKIM, DMARC) and any verification records, before the nameservers change.
Set sensible TTLs
For records that rarely change, a TTL of several hours or more is normal. Lower it a day or two ahead of a planned move, then raise it again once the move has settled.
Shorten alias chains
Where a record goes through several CNAMEs, see whether your provider can point it more directly. Some DNS services can flatten a chain so the resolver gets the final address in one step.
Cut other domains, and give the browser a head start on the rest
Remove third-party services the page no longer needs. For ones you keep and that load early, a resource hint can start the lookup sooner, for example <link rel="dns-prefetch" href="https://fonts.gstatic.com"> in the page head. A related hint, preconnect, goes a step further and opens the connection too. Use them only for a few domains that matter early in the load; hinting at everything wastes effort.
Mistakes to avoid
- Changing nameservers without copying email records. The site may load faster and the mailboxes stop receiving.
- Leaving a migration TTL in place for years. It was meant to be temporary.
- Judging DNS from your own office. Your resolver has your domain cached because you visit it all day. Test from other locations.
- Blaming DNS for a slow server. If the DNS segment is short and the waiting segment is long, you are looking at the server. Whether that means the hosting itself is explained in does hosting affect website speed, the guide to this section.
DNS is one of the small, fixed costs at the start of every visit, and part of the bigger picture in our page speed guide.
Frequently asked questions
Is my registrar’s free DNS good enough?
For many small sites, yes. The test is evidence rather than the name on the account: check lookup times and consistency from several locations. If answers are quick and reliable, there is little to gain from moving. If they are slow from regions where your customers are, a managed DNS service is worth considering.
Does a slow DNS lookup affect returning visitors?
Much less. Returning visitors usually have the answer cached in their browser, device or resolver, as long as the TTL has not expired. The visitors who feel it most are first-time visitors and those whose cached answer has just run out, which is why short TTLs make the effect more common.
Will moving DNS to another provider cause downtime?
It does not have to. If every record is copied to the new provider before the nameservers are changed, both old and new give the same answers while the change spreads, and visitors do not notice. Problems come from missing records, most often for email or subdomains, so compare the two record lists carefully first.
How many third-party domains is too many?
There is no fixed number. What matters is how many load early, before the main content appears, and whether each one earns its place. Look at your waterfall for DNS segments before the largest content element loads; those are the lookups that delay what visitors see, and the first ones to question.
If nobody can say where your domain’s DNS lives, or you want it moved without losing email, that falls under our domain and DNS support. We review the current DNS and hosting setup, share a fix plan with the price before making changes, then update the records and monitor propagation until the site and mail are confirmed working.
Next in this series: When to Upgrade Hosting for Speed: Three Tests First
