Resolving a domain name into an IP address is probably not a performance bottleneck for your site. To be honest, there are limited performance gains to be had with DNS lookups. That said, I think there are some good reasons to understand DNS better both in general and in terms of performance.
The optimizations you implement for quicker DNS lookup times are easy to make and are mostly of the set and forget type. You can spend five minutes to make a few tweaks that will shave time off the loading of your website. The time might be measured in milliseconds, but it’s not like there’s any great investment to get there.
It’s also possible you do have some issue with DNS and knowing a little more about domain name servers and their performance might help you identify and correct what could be a serious problem and bottleneck.
This is the second post in a second series about website performance. Last week I talked generally about the time to first byte (TTFB) and what’s coming throughout this series. Today’s agenda is, of course, DNS.
Testing and Goals
If you want to improve the speed of DNS lookups to your site, you should first know how to find your current DNS times. You should also find out what is and isn’t a good time. Both will turn out to be a little harder than you might think.
Last week I mentioned a tool from KeyCDN to find the time to first byte (TTFB). The same tool breaks out DNS Lookup times from 14 different physical locations giving you a variety of results.
When I first ran the KeyCDN test I received a time of 4.3ms when accessing this site from New York, which is where the server is physically located. I also saw times as high as 1.5s or 1500ms when requesting the site from Sao Paulo, Brazil. I’ll talk more about the wide variety in a bit.
I’ve used the performance tool at WebPageTest in the earlier series and you can get DNS times from the same tool. Run the test, click through to results, and scroll down to find DNS times.
The WebPageTest tool showed 38ms for the DNS Lookup to the home page of this site. I didn’t change the location from the default Dulles, though you would naturally want to test against multiple locations for more results. Of course, the same tool run a week earlier also from Dulles showed 69ms for the same DNS lookup. Like I said, results can vary, this time from one week to the next.
One nice thing about the WebPageTest tool is it also gives you times to lookup DNS for 3rd party files you included in your HTML. It lets you see if any of your 3rd party code is causing a problem.
If you want more real data, you can get DNS times through Google Analytics. Go to Behavior > Site Speed > Page Timings. Then click on the Technical tab toward the top. From there you’ll be able to select Avg. Domain Lookup Time (sec) from the drop down.
Google will show you the average DNS time for your site based on actual visitors to your site from whatever locations they happen to be. Over the last 30 days Google showed average DNS times to this site as 0.15s or 150ms.
With three tools showing a wide variety of results, which should you trust? Good question, but one without a definitive answer other than to be consistent when testing and always compare before and after results using the same tool. It won’t guarantee perfectly consistent results, but it will eliminate some potential causes for variety in the results.
Finding acceptable times was more difficult than finding tools to measure them, so difficult that I never found any definitive recommendations.
I don’t remember where I found these numbers so take them with a grain of salt, but a suggested high end for acceptable DNS times was about 125ms and under 15ms when the lookup accesses a cache of the DNS instead of having to hit the DNS server over the network. Keep in mind we want the time to first byte (TTFB) to be no more than 200ms and DNS is only one part of TTFB.
WebPageTest provides times for first, second, and third runs. Second and third runs access cached DNS and the results of these cached tests have generally been under 10ms. I’ll talk more about DNS caching next week.
The results from testing should help you see that it’s difficult to measure DNS times accurately and some would argue there’s not much you can really do to improve these times. In many ways that’s true, but the difference between the first run times and those that use cached DNS information suggest we can do something and not nothing.
CName vs. AName
In the previous series I talked about DNS lookup as the way to map a domain to an IP address. Your hosting company owns a bunch of IP addresses and when you set the name servers for the site with your registrar, the domain then points to your hosting company’s servers.
Before the mapping can occur you, or your host, sets the DNS records for your domain or account. Odds are it’s your hosting company and you never pay any attention to this, but depending on your account you may have control over setting or modifying the DNS records for your domain.
DNS records are basically files with domain to IP mapping information so user-agents can discover that domain.com is located at the IP 123.456.789.012.
There are a variety of different types of DNS records, but here we’re concerned only with those for domain mapping. There are two common types of domain mapping records, CName records and A records.
- An A record maps a domain or subdomain to a single IP address.
- A CName record points to another domain instead of an IP address.
If you run a part of your site on a subdomain, a CName record will point the subdomain back to the main domain. Keep in mind that the www in www.domain.com is technically a subdomain of domain.com. Same for ftp.domain.com. You might also redirect from domain.net to domain.com or domain.co.uk or many similar domains.
Imagine how many records you might need to update if you move to a new IP address. That’s the advantage of using CName records in that you (or your host) ultimately has only one record to update, the A record pointing to the IP.
However, because CName records point one domain (or subdomain) to another they require additional lookups until an A record is eventually reached.
I don’t expect you to mess with any of this. The convenience of CName records outweigh the additional lookup and in all likelihood your host has this set up the way you want, but I thought it something worth talking about and if you do have control over the DNS records of your site, reducing CName records where possible could help a little with performance.
The discussion also makes a point about redirection in general. It’s not uncommon to change URLs and set 301 redirects from old to new. Know that this requires an extra DNS lookup meaning redirected pages will take a little extra time to load. There are certainly valid reasons for redirection, but be aware of the downside and maybe don’t chain a bunch of redirects together.
Reduce DNS Lookups
I mentioned that the WebPageTest performance tool showed DNS lookup times for the 3rd party files the page requests. That suggests that one way to improve times is to reduce how many domains you link to as each needs its own DNS lookup.
For example, as I’m writing this page has buttons at the bottom to some of my social profiles. Each makes a call to another domain and requires an additional DNS lookup. As I rarely look at any of these social sites, I could remove the buttons and shave some time.
It’s not only third party code. What about images and other media? If you host them on different domains, each requires another lookup. You probably still are better off letting YouTube host the video, but consider your site being located at domain.com and using www.domain.com as the source of your images. That’s an extra lookup for the image.
Any request for a resource on an external server will require another DNS Lookup so where possible you want to reduce the number of different domains to reduce the number of DNS lookups required to load your pages.
Closing Thoughts
While DNS lookup times are probably not a major contributor to performance issues with your site, it’s always possible there’s a significant issue with how its configured and it’s worth testing DNS times just in case.
You likely will want to remove additional DNS requests by minimizing requests for 3rd party resources and being consistent with how you refer to resources on your domain. You also want to reduce redirection as much as possible to further reduce requests for DNS lookups.
Next week I want to look into DNS caching and how we can suggest that browsers look to local cache for DNS records before sending a request over the network. This is where you’ll see the most DNS optimization gains.
Download a free sample from my book, Design Fundamentals.