Minimize the DNS Duration Sub-part of the Time to First Byte

Minimize the DNS Duration Sub-part of the Time to First Byte

This article is part of our Time to First Byte (TTFB) guide. The DNS duration is the third sub-part of the TTFB and represents the time the browser spends resolving your domain name to an IP address. For first time visitors who do not have a cached DNS record, the DNS lookup can add 20 to 200 milliseconds to the TTFB depending on the DNS provider, the geographic location of the user, and the TTL settings of your DNS records.

The Time to First Byte (TTFB) can be broken down into the following sub-parts:

• Waiting + Redirect (or waiting duration)
• Worker + Cache (or cache duration)
• DNS (or DNS duration)
• Connection (or connection duration)
• Request (or request duration)

Looking to optimize the Time to First Byte? This article covers the DNS duration part of the Time to First Byte. If you are looking to understand or fix the Time to First Byte and do not know what the DNS duration means, please read what is the Time to First Byte and fix and identify Time to First Byte issues before you start with this article.

DNS Quick fix: if you are experiencing DNS latency in the Time to First Byte, switch to a premium DNS provider and update your TTL settings!

The DNS Duration part of the Time to First Byte consists of the time where the browser is looking up the internet (IP) address for your site. We need DNS lookups because us humans find it easier to remember domain names like "www.example.com" while computers require numerical IP addresses to connect with each other.

How Does DNS Work?

DNS requests are included in the TTFB measurement. This means that the time it takes for the DNS request to finish is factored into the overall TTFB score.

When a page is requested, these are the steps your browser takes to convert the domain name into an IP address:

• The browser's DNS cache is checked: Before making a DNS query, the browser first checks its own DNS cache to see if it already has the IP address for the requested domain. Modern browsers cache DNS records for a set period to improve performance by reducing the need for repeated DNS lookups. If the record is found in the browser's cache, the browser can use it immediately without further queries.
• The OS System cache is checked: If the browser's cache does not contain the needed DNS record, the request is passed to the operating system's DNS resolver, often called a "stub resolver." The OS also maintains a DNS cache and will check it before sending any network requests.
• DNS Query: If the DNS record is not found in either the browser or the OS cache, a recursive DNS query is sent to a DNS resolver, typically provided by the user's Internet Service Provider (ISP). This resolver acts as an intermediary, handling the process of querying other DNS servers to find the IP address.
  • Root Name Servers: The resolver first contacts a root name server, which directs it to the appropriate top-level domain (TLD) server based on the domain extension (e.g., ".com", ".org").
  • TLD Name Servers: The TLD server then directs the resolver to the authoritative name server for the specific domain.
  • Authoritative Name Server: This server holds the DNS records for the domain and provides the resolver with the IP address.
• Return the IP Address: Once the DNS resolver obtains the IP address from the authoritative server, it returns this information to the browser. The browser can then initiate a connection to the server using the IP address to load the requested webpage.

How Does DNS Impact the Time to First Byte?

For repeat visitors, the DNS lookup is typically cached in the browser or OS, reducing the DNS duration to near zero. For first time visitors, however, the full recursive DNS lookup must complete before the browser can proceed to the TCP connection step. This is why TTFB is often measurably worse for new visitors compared to returning ones.

Use dns-prefetch and preconnect for Third-party Domains

If your page loads resources from third-party domains (such as analytics, fonts, or CDN subdomains), the browser must resolve DNS for each domain separately. You can instruct the browser to start DNS resolution early by using the dns-prefetch resource hint:

<!-- DNS prefetch for third-party domains -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

For critical third-party origins where you know you will also need to establish a TCP and TLS connection, use preconnect instead, which includes DNS resolution plus the connection handshake:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Use dns-prefetch as a fallback for browsers that do not support preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

Place these hints in the <head> of your HTML as early as possible. Only add hints for domains your page actually uses; adding hints for unused domains wastes browser resources. For more optimization techniques related to resource loading, see our guide on 103 Early Hints.

How to Minimize DNS Impact on the TTFB

Use a Fast DNS Provider

Some DNS providers are faster than others. Choosing a fast and reliable DNS provider is one of the easiest ways to reduce DNS latency. Premium DNS providers like Cloudflare, Amazon Route 53, and Google Cloud DNS run servers across hundreds of locations worldwide. The closer the DNS server is to your user, the faster the lookup.

Here is a comparison of popular DNS providers and their typical response times:

The difference between a premium DNS provider and a basic registrar DNS can be 40 to 90 milliseconds per lookup (source: DNSPerf benchmarks). For first time visitors, this directly translates to a faster TTFB. To learn how to set up Cloudflare as your DNS and CDN provider, read our guide to configuring Cloudflare.

Optimize the DNS Cache Time to Live

DNS caching stores DNS query results locally, reducing the need for repeated lookups. By setting "optimal" Time-To-Live (TTL) values for DNS records, you can control how long these records are cached.

Lower TTL values mean records expire sooner, causing more frequent DNS lookups. Higher TTL values mean records are cached longer, reducing DNS lookups but making DNS changes propagate slower. The right TTL depends on how frequently you change your DNS records and how much you value DNS lookup speed versus flexibility.

What Are Optimal DNS TTL Settings?

When planning a DNS migration or server change, temporarily lower your TTL to 5 minutes (300 seconds) at least 24 hours before making the change. This ensures that after the change, users will pick up the new IP address quickly. Once the migration is complete and verified, increase the TTL back to a higher value to reduce DNS lookup frequency.

TIP: if you are using CNAME records, consider implementing CNAME flattening. CNAME flattening is a technique that allows you to use a CNAME record at the root (apex) domain level, effectively resolving it to an IP address without violating DNS standards. This eliminates an extra DNS lookup that would otherwise be needed to resolve the CNAME to its target, then the target to its IP address.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Traditional DNS queries are sent in plain text over UDP, which means they can be intercepted, modified, or blocked by intermediaries (such as ISPs or network operators). DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries, improving both privacy and security.

While DoH and DoT primarily address security and privacy concerns, they can also affect DNS resolution performance:

• Latency impact: the encryption overhead adds a small amount of latency to the initial DNS connection (TLS handshake). However, because DoH/DoT connections are persistent and reused, subsequent queries on the same connection are often faster than traditional DNS.
• ISP interference: some ISPs inject their own DNS responses or slow down DNS queries for non-customers. DoH bypasses this interference entirely, which can actually improve DNS resolution time for affected users.
• Browser support: modern browsers (Chrome, Firefox, Edge, Safari) all support DoH. In most cases, the browser's default DNS provider already uses DoH when available.

For website owners, you cannot control whether your visitors use DoH or DoT (that is a browser and OS-level setting). However, you can ensure your authoritative DNS provider supports DNSSEC, which provides a complementary layer of verification for DNS responses regardless of transport encryption.

Measuring DNS Duration with JavaScript

You can measure the DNS duration sub-part of the TTFB directly in the browser using the Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

A DNS duration of 0ms in your RUM data typically indicates that the DNS lookup was served from the browser or OS cache (a repeat visitor scenario). Values above 50ms suggest the user had to perform a full recursive DNS lookup, which is common for first time visitors.

How to Measure TTFB Issues Caused by Slow DNS Lookups

To find the impact that real users experience caused by DNS latency, you will need to use a RUM tool like CoreDash. Real User Monitoring will let you track the Core Web Vitals in greater detail and without the 28-day Google delay.

In CoreDash, click on "Time to First Byte breakdown" to visualize the DNS part of the Time to First Byte.

Further Reading: Optimization Guides

Related guides:

• 103 Early Hints: send resource hints before the full response is ready, allowing the browser to start DNS resolution and connections for critical resources even earlier.
• Configure Cloudflare for Performance: use Cloudflare as both your DNS provider and CDN, combining fast DNS resolution with edge caching and HTTP/3 support.

TTFB Sub-parts: Complete Guides

The DNS duration is one of five sub-parts of the TTFB. Explore the other sub-parts to understand the full picture:

• Fix and Identify TTFB Issues: the diagnostic starting point for all TTFB optimization.
• Waiting Duration: redirects, browser queuing, and HSTS optimization.
• Cache Duration: service worker performance, browser cache lookups, and bfcache.
• Connection Duration: TCP handshake, TLS optimization, HTTP/3, and preconnect.
• Request Duration: server processing time, database queries, and backend optimization.