Minimize the DNS duration sub-part of the Time to First Byte

Minimize the DNS duration sub-part of the Time to First Byte

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 provides an in-depth analysis of 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 waiting duration means please 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 some 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?

• Use a Fast DNS Provider. Some high quality DNS providers are faster than others. That is why 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 Dyn have extensive global infrastructures. Those infrastructures reduce the physical distance between users and DNS servers and remove an important part of the latency involved in DNS requests.
• 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.  
  

What are optimal DNS TTL settings

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 

How to measure TTFB issues caused by slow DNS lookups

To find the impact that real users experience caused by redirect you will need to use a RUM tool like CoreDash. Real user monitoring will let you track the Core Web Vitals into greater detail and without the 28 day Google delay.

In CoreDash simply 'click on Time to Fist Byte breakdown' to visualize the DNS part of the Time to First Byte.