Table of Contents
Last update on
When it comes to decreasing your website’s load times, one aspect that’s often overlooked is your DNS and how quickly it responds.
DNS (Domain Name System) is the part of your server setup that translates your domain to the IP address of your site.
Without it, users would need to remember the long string of numbers of your IP to visit your website instead of a user-friendly address.
Since Google’s research indicates your website’s bounce rate can increase by 32% if it loads between one and three seconds, it’s incredibly important to shave off as much time as you can from page load speeds.
Today, I’ll share more details on DNS testing as well as how you can run your own DNS response time test to see if you can improve the performance of your DNS and website’s speed.
Two Methods and Two Very Different Tests
Typically, many site owners and developers run ping tests to determine the average time it takes for a site to load.
While these tests provide valuable details, they may not always be reliable.
Some servers mark pings as inessential and don’t respond to pings. When this happens, you won’t be able to generate data on how fast your site loads.
Ping tests also don’t often reveal how fast your DNS responds and fetches the IP address to load a website.
That’s where the BIND tool comes in.
You can use it to run a DIG (Domain Information Groper) command to work out your exact DNS response time.
It’s included on Mac and can be downloaded and installed for Windows.
Using DIG to test DNS Server Response Time
To run a DIG command and DNS response time test, go to your Applications folder on Mac and open the Terminal app.
For Windows, go to Start > Run, enter “cmd” (without the quotation marks) into the field, and press Enter on your keyboard. Then, click on Command Prompt to open it.
Next, type in the command in the link below, but don’t forget to replace “your-site.com” with your actual domain before pressing Enter on your keyboard:
You should receive a result similar to the one below for Twitter’s DNS response time test:
The two key components to note are query time in milliseconds on line 18 in the example above and real on line 24.
The real-time is noted as minutes, then seconds, followed by a period, and the milliseconds after that.
The query time is how long it took for your computer to execute the command. The real-time indicates how long it took for your computer to reach your site’s DNS.
Now, you need to solve a quick math problem to get the actual time it took to get a DNS response.
Subtract the real-time from the query time to get how long it took for the DNS to respond.
In the above example, the query time is 38 ms and the real-time is 118 ms. The result of the DNS response time test is 80 milliseconds.
It may be important to note that if one of the results is in seconds and the other is in milliseconds, you need to first convert the one result from seconds to milliseconds.
You can do this by multiplying the time in seconds by 1000.
Digging Deeper into a DNS Response Time Test
The resulting DNS response time test shows only one metric from your computer. To get more accurate results, it’s crucial you run tests from different locations.
You can use Google’s Public DNS, for example, to run more tests.
Go back to your Terminal app or Command Prompt and enter the following command:
Don’t forget to replace “your-site.com” with your real site address.
The results are similar to the previous command and you can subtract the real-time from the query time to get the DNS response time.
You know how to test DNS server response time using the DIG command, but how reliable are your results, exactly?
The Problem When You DIG for Results
While the BIND tool and DIG commands are helpful, there are some caveats.
Have No Fear, You’re (Probably) in the Clear
Lighting-fast DNS speeds are significant, but that’s not the only factor you should consider when you’re trying to improve your site’s performance.
Many DNS options out there are sufficient. Unless you’re experiencing an alarmingly large DNS response time close to or much longer than a second for a small to the medium-sized site, you’re probably in the clear.
Although, this isn’t a hard and fast rule. Each site is different. It’s up to you to decide what’s an appropriate DNS response time since it will vary based on the purpose of your website.
As Valuable as Your DNS’s Speed
How quickly your site’s DNS performs isn’t the only factor you should consider. What’s equally critical is that your DNS is secure, reliable, and your provider acts ethically, professionally, and takes your privacy seriously as well.
If security and privacy aren’t a priority for you, it should be since hackers can cause an abundance of issues for your site’s speed.
For example, they could inject scripts that add spam to your site that increases load times, or redirect your domain to point to their own spam, malware, or phishing website.
If your DNS isn’t reliable, it could be slow one minute, then fast another, and your visitors could get downright annoyed in the process, and decide to leave your site altogether.
Similarly, your hosting provider should also help you out with any DNS issues courteously and quickly. Otherwise, you could struggle with your site’s speed for the long haul.
Possibly Skewed Results
The DIG command does what’s called a DNS lookup, but only from your computer or another DNS of your choosing.
Depending on how close your site’s DNS is to your computer or the DNS you used to run the test, you may not get accurate results for how your users experience your site’s speed.
If you’re located near your DNS and server, then you’re going to get much faster response times than a user from the other side of the world and vice versa.
Not every one of your users will likely visit your site from your location. That means some of your site’s visitors may experience higher or lower response times depending on how far they are away from your site’s DNS and server.
Getting results from only one or two different DNS and locations isn’t going to provide an accurate overview of the average DNS response time for your site.
Ideally, Google’s Public DNS would be located on the opposite side of the world from your computer’s location, and your site’s DNS would be located near either you or the public DNS.
In that case, your results wouldn’t be as limited.
But, this may not be the case.
Fortunately, there are automated tools you can use to get more accurate results when you test DNS server response time.
Tools to Test DNS Server Response Time
Both tools below can be used for free, and without needing to download any software. They’re both reliable, secure, and offer detailed reports after each DNS response time test.
DNSPerf
The DNSPerf tool runs real-time tests from over 30 different locations so you can get a thorough review of how well your DNS is performing across the world.
Each location is marked with the time it took for your DNS to respond, and insufficient times are highlighted in yellow as a warning, or in red to denote critical speed issues.
Results are displayed in list form as well as on a map for clarity.
UltraTools
UltraTools runs several tests to find speed averages for more accurate results. It also uses authoritative DNS servers in their tests so data isn’t skewed by underperforming DNS that likely no one uses, anyway.
It also displays the lowest and highest response times of each server your site uses.
So, there’s no need to worry if your site runs on server clusters. You’ll be able to see DNS response times for all of them.
Wrapping Up
Shaving off milliseconds – or seconds – off your DNS response time can help decrease your site’s load times quite significantly in some cases. It will also help improve the LCP grade, one of the Core Web Vitals.
Running a DNS response time test using the DIG command can help you determine whether your DNS is performing well, or if improvements need to be made.
Either way, you’ll know if your DNS speed is up to snuff.
Do you test DNS server response time? Have you considered your DNS when evaluating your site’s overall performance? Feel free to share your experience in the comments below.
