By Billy Hoffman
A DNS Prefetch is a resource hint to make a DNS lookup for a domain the browser has not yet determined needs to be made. This can improve performance because when the browser does need to make a request for a resource, the DNS lookup for that domain has already occurred.
Let’s see an example. The browser is loading a page and needs to request the resource https://stats.example.com/js/pinit.js. To do this, it first must make an HTTP connection to the domain stats.example.com. If the browser already has an HTTP connection to the domain, the existing connection can be used, otherwise a new connection is created. To do this, the browser first makes a DNS lookup for stats.example.com. In the screenshot below, you can see the request for pinit.js:
We can optimize this by adding a DNS prefetch resource hint in the <head> of the HTML file, as shown below:
<link rel="dns-prefetch" href="https://stats.example.com/">
In the screenshot below, you can see that the browser was instructed to proactively attempt a DNS lookup for stats.example.com where pinit.js is located:
When the browser later determines that it needs to request pinit.js and makes a connection to stats.example.com, the DNS lookup has already occurred. This allows the JS file to download more quickly, shifting the overall waterfall to the left.
DNS Prefetch and Preconnect
DNS Prefetching is just one of many different kinds of resource hints a site can use to instruct the browser to do something before it otherwise would. It is a small, fairly basic resource hint which allows it to be applied more broadly than other options.
Preconnect is a similar type of resource hint, which tells the browser to proactively make an HTTP connection to a domain. Preconnect is a super-set of the DNS prefetch functionality, because making an HTTP connection involves a DNS lookup, a TCP connection, and negotiating a secure TLS connection.
You don’t need to specify both a DNS prefetch and a preconnect resource hint. The browser will do all the steps it needs to do with just a preconnect.
DNS prefetch is still important, and can be used in conjunction with preconnect hints. This is because browsers place limits on the number of HTTP connections they will maintain. Using more than 6-8 preconnect resource hints can limit the browser from making connections they actually need. DNS prefetches operate at a different level, which means you can have 6-8 preconnects to critical domains on the page, and then have additional DNS prefetch hints to other, less-critical domains.
When Should You Use DNS Prefetch?
In general, DNS prefetch should be used for important first party domains and third party domains including:
- Domains that are discovered later in the waterfall
- Domains with resources that then cause other requests to occur
- Domains with a lot of requests, or which download a large amount of content
- Domains are not already used by another type of resource hint
As a rule, DNS prefetch should not be used for domains that are part of the critical rendering path. This is because, ideally, those domains should use a preconnect resource hint.
DNS Prefetch and First Party Domains
Using DNS Prefetch for first party domains tends to be easy, for a variety of reasons:
- You control the domain name.
- You are purposefully hosting content on that domain and linked to it for a page.
- You should know ahead of time what first party domains a page will use.
- The domain name is unlikely to change.
These factors allow you to include a DNS prefetch resource hint with some degree of confidence that the domain contains resources that are needed by a page and that they are unlikely to change.
Good examples include:
- Other domains with images or videos that have deferred loaded
- First party domains for API endpoints that are used later in the page
Third Party Content and DNS Prefetch
Using DNS prefetch resource hints with third party domains can be very challenging, for a variety of reasons:
- The domain name could be dynamic or change without your knowledge
- Different third party domains may be used for different parts of your site
- It may not be clear which third party content is loading from which domains, so adding or removing third party tags can add or remove domains that need DNS prefetching
- Third party domains could be appearing because of actions by another department, such as a marketing or business group using a tag manager.
You may need to do extra work to determine the source of the third party content. Ideally you want to use DNS prefetch for third party content which will be consistently used by your pages for a long period of time.
The following are good examples of third party content to use with DNS prefetch because they tend to have consistent domains or URLs:
- Analytics or activity trackers
- A/B Testing widgets
- Chat widgets
- Error and Logging frameworks
- Social sharing widgets
Ads can be especially difficult to optimize with resource hints. This is because, while the initial ad exchange may have a well known domain name, the ultimate domain serving the ad is often unknown and inconsistent.
Validating the Benefits of DNS Prefetching
Once you have determined which domains should use DNS prefetching, you still need to test it! Just because something should improve your site’s performance or experience, that does not mean it actually will: you need to always test to make sure. Start by baselining your performance with synthetic tools, implement your change, and then compare the “before” and “after” performance metrics.
Excessive DNS Prefetching
When people first hear about DNS prefetching, they immediately think:
Since DNS prefetching can make later calls in the waterfall happen faster, why don’t I DNS prefetch to all the domains that might be used by a page?
You can see this thinking in the wild. For example, here is a major news site, making 33 DNS prefetches!
Remember that each type of resource hint asks the browser to override which tasks it would normally perform. Using an excessive number of DNS prefetches can lead to performance issues since browsers place limits on the number of outstanding DNS requests they will maintain. Using DNS prefetch to force a DNS lookup is “using up” an available slot that the browser could otherwise use for a DNS lookup the browser knows it needs. Making too many DNS prefetches, or doing a DNS prefetch for a domain that ultimately is not used, creates resource contention and can make the browser operate inefficiently.
As a general rule, websites should try not to make more than 10 DNS prefetches.
Other DNS Prefetch Issues
There are additional issues to be aware of when using DNS prefetching, especially with other resource hints.
Unused DNS lookups
Don’t make DNS prefetches to domains that aren’t even used by a page. It’s just a waste and will impact the browsers ability to make other DNS lookups for domains that are actually needed.
Don’t DNS Prefetch and Preconnect to the same domain
There is no reason to include both a DNS prefetch and a preconnect hint to the same domain for “backwards compatibility.” As of 2020, more browsers support preconnect than DNS prefetch, and the browsers that do support DNS prefetch also support preconnect. If a domain is critical, use preconnect. If it is less important, use DNS prefetch.
Avoid the Safari Bug
As mentioned above, you should not perform a DNS prefetch and a preconnect for the same domain. In addition, you should definitely not do it inside of the same tag like this:
<link rel="preconnect dns-prefetch" href="https://example.com/">
There is an implementation issue with Safari (on macOS, iOS, and iPadOS) which causes it to ignore resource hints when there are two hints inside the same rel attribute. In effect, specifying multiple resource hints disables the hint for Safari! See our definitive guide to Preconnects for a detailed discussion of preconnect resource hints.
Auditing for DNS Prefetch Best Practices
We have seen there are many benefits with using DNS prefetch resource hints, but also many pitfalls that hurt performance if you use them incorrectly. This means it is important to audit how a page is using resource hints to ensure you are following all of the best practices.
First, identify all of the DNS prefetch resource hints a page is currently using. You will want to look for <link rel="dns-prefetch"> tags in the base HTML page, as well as Link: HTTP headers which can also contain resource hints. Also remember that Link headers containing resource hints can appear on other responses beyond just the based HTML page!
Once you have listed all of the DNS prefetched domains, ask yourself the following questions:
- Using the guidance above, I need to determine which domains should use a DNS prefetch. Are they on the list of hints the page is already using? If not, why not?
- Am I using more than 10 DNS prefetches? If so, that is too many and you should consider removing them.
- Are there any domains that are using a DNS prefetch that should instead be using preconnect?
- Am I using preconnect and DNS prefetch for any of the same domains? If so, remove the DNS prefetch hint to that domain.
- Am I using multiple resource hints in the <link rel=""> tag and triggering the Safari issue? If so, remove it.
- Are all the DNS prefetches used? Most waterfall charts will allow you to filter by the domain or parts of the URL, as shown below. This makes it much easier to see if a domain is actually used by the page:
If this feels overwhelming and you are looking for an automated solution or want to do this validation at scale, you have options. Splunk Synthetic Monitoring automatically audits pages for 13 different issues that can occur when using resource hints: