How it Works
What DNS prefetching does is attempt to resolve domain names before we, the users, try to follow a link. This is accomplished using the computer’s built-in DNS resolution mechanism. Once a domain name has been resolved, if we do navigate to that domain, there will be no effective delay due to DNS resolution time. While downloading speed remains the same, looking up the IP address before hand will save you an easily perceptible second or two when going from page to page. A good example where DNS prefetching can really help is when a user is looking at a page with many links to various domains, such as a search results page. When the browser encounters an a hyperlink that does not share the same domain name as the current location, it first checks its cache and then, lacking a cached copy, resolves the domain to the associated IP address through a request from a DNS server. These requests happen in the background so as to not block the rendering of the page. Moreover, since all this takes place in parallel with the user’s reading of the page, it places only a negligible load on CPU and network resources. How much navigation time will a user save can range from an average savings of about 200 milliseconds for non-cached content, to one to two seconds for the worst DNS resolution delays.
By default, prefetching of embedded link hostnames is not performed on documents loaded over HTTPS. You can change this by setting the network.dns.disablePrefetchFromHTTPS browser preference to false.
Controlling DNS Prefetching for Specific Hostnames
Although you can expect the user’s browser to automatically prefetch any hyperlink that appears in your pages you can force the lookup of specific hostnames without providing specific anchors using that hostname by using the rel attribute on the <link> element with a link type of dns-prefetch. In the following example, the browser will pre-resolve the domain name “www.robgravelle.com”:
<link rel="dns-prefetch" href="http://www.robgravelle.com/">
The link element also supports protocol relative URLs, where the protocol is omitted, and the hostname is preceded by two forward slashes (//). These are useful when the exact protocol may vary or is uncertain:
<link rel="dns-prefetch" href="//www.robgravelle.com/">
A good place to use forced prefetching of hostnames is on the home page of a site for domain names that are referenced frequently throughout the site even though they’re not used on the home page itself. This helps improve overall site performance even though the performance of the home page may not be affected.
The recommended best practice is to have your prefetch requests queued to the client OS as early as possible. It is also preferred to have them received in the first packet of the HTML. Therefore, explicit prefetch links should be placed immediately after the “meta charset” tag:
<!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="dns-prefetch" href="//www.robgravelle.com/"> ...
Turning off Prefetching
In general, you don’t need to do anything to manage prefetching. However, should you wish to disable prefetching, it can be done by setting the network.dns.disablePrefetch preference to true.
On the server-side, a server can opt out of DNS prefetching by serving content with the x-dns-prefetch-control: HTTP header set to “off”.
You can also turn off DNS Prefetching from individual documents, using the http-equiv attribute on the <meta> element, like this:
<meta http-equiv="x-dns-prefetch-control" content="off">
After the adoption of several browser optimizations have already raised security concerns, early signs are already pointing to similar concerns with DNS prefetching. In particular, DNS prefetching may amplify disclosure attacks by inferring the likely search terms issued by clients using a given DNS resolver. Sites like Google already try to guess at which site’s you’re likely to visit (or might want to visit) based on previous search queries. Anyone who can intercept your search criteria can also send back dubious or malicious links.
Although DNS Prefetching is not taxing to your own computer or mobile device, it can use up all of your allotted bandwidth if performed enough. In some cases, browser DNS prefetching has been found to cause an increase in DNS queries of 800%! The use of meta tags to control prefetching can drastically reduce these numbers.
Apple’s site offers two workarounds for poor performance directly related to DNS prefetching. This can happen if your DNS server (or router) does not play well with DNS prefetching.
The first suggestion is to switch to a different DNS service that works better and/or faster. You can go to Network System Preferences and, from the Advanced section of the connection service you are using, add the name of the new server to the DNS listing.
The second option, if the first doesn’t have a beneficial effect, is to disable DNS prefetching altogether. To do this, Apple explains to “launch Terminal and type the following”:
defaults write com.apple.safari WebKitDNSPrefetchingEnabled -boolean false
After you quit and relaunch the browser, prefetching will no longer be active.
DNS Prefetching is clearly not a one-size-fits-all type of optimization. Depending on the nature of your site and users’ navigation patterns, it can either be of great benefit or a drain on your ISP bandwidth allocations. The key is to be aware of DNS Prefetching’s implications and decide for yourself how much of – if any – it to utilize on your own site(s).