Remember 'Charmed'? Three sisters use witchcraft to save the world, etc? They had a magic book that held the answer to every conceivable question, and it made an appearance in most of the episodes that I saw. Which wasn't many, because I wasn't actually that much of a fan. Honestly, hardly ever watched it. No, really….
Anyway, when I look at the page source for CSS Wizardry, I feel like Piper, Phoebe and Prue (or whatever), opening the big magic book and learning all kinds of weird stuff. This week it's DNS prefetching, a mystical web-dev way to help the browser deliver content from external sources a little faster.Skip to navigation
What is DNS prefetching?
Harry Roberts, author of CSS Wizardry, has himself written a guide to DNS prefetching (among many other things): Front-end performance for web designers and front-end developers. If I've understood correctly, when we see a URL like ‘csswizardry.com’, this is simply the human-friendly name for the site. In order to get data from an external website, what your device really needs is the numerical IP address of the server where the site is hosted. To get the IP address, your device sends off a request to the DNS, whose function is described on Mozilla Developer Network:
DNS (Domain Name System) translates easy-to-recall domain names to the numerical IP addresses needed to find a particular computer service on the Internet or private network.
It takes time for the request to reach the DNS and for the response then to be returned, which can range from a few milliseconds to several seconds. DNS prefetching can speed things up a little. As described in How your browser speeds up cross domain loading using DNS prefetching, this DNS request takes place automatically for all anchors that contain links to an external server. There's no need to explicitly prefetch these domain names.
<link> tag in the
<head>, which instructs the browser to obtain the IP address associated with a given website before the IP address is required. This happens in the background while the browser is idle, so the user is unlikely to notice that it's happening. If any assets, such as fonts, are needed for the page to load, DNS prefetching can hurry things along, even if it's just by milliseconds.
Markup and syntax
The syntax for these link tags is as follows:
These are the link tags used in CSS Wizardry:
hrefs? Use a double slash ‘//’ if you're not sure which protocol (http, https, etc) the page uses.
Which domains should we prefetch?
It looks to me like some thought has gone into which domains have been prefetched, as well as their position in the head section. Let's have a closer look.
The first two prefetched domain names are related to Google fonts. In fact, these two tags come directly before the links to the external stylesheet for Google fonts:
The answer to this question on Stack Overflow, DNS prefetch Google webfonts - which domain?, discusses prefetching domains for Google fonts and ‘chained’ server calls. The first location in the above markup, I guess, is where the font stylesheets are stored, while the second must be where the font files themselves are downloaded from. If I'm right, the fonts.googleapis.com domain calls googleusercontent.com, so it makes sense to place one before the other, and to position both of them before the link to the stylesheet. In fact, in the above Stack Overflow conversation, the responder Anew says that:
It's best if [all DNS prefetch links] are all immediately after the Meta charset element (which should go right at the top of the head), so the browser can act on them ASAP.
The sixth line looks self-explanatory. If your site collects data for Google Analytics, prefetching this domain is a good idea. Since you've probably included your GA script at the bottom of your HTML document, I guess it doesn't really matter if this DNS prefetch link appears later in the head.
Twitter's follower count widget downloads data from, count 'em, three different domains (platform.twitter.com, twitter.com and cdn.syndication.twimg.com; not sure why the first one is repeated—an oversight maybe?), as does the widget for advertisements (cdn.adpacks.com, stats.buysellads.com, and s3.buysellads.com; again, the last one appears twice). Are all these domain name prefetches really necessary? In the same article as above, Roberts talks about ‘parallelisation’. As he says:
In order to get the browser to download more assets in parallel, you can serve them from different domains. If a browser can only fetch, say, two assets at once from a domain, then serving content from two domains means it can fetch four assets at once; serving from three domains means six parallel downloads.
This would explain the number of DNS prefetch links. The question that occurs to me is: as a developer, how do you know which domains a particular widget needs to download assets from? Perhaps if the widget is well-documented, it will tell you. Again, these look non-urgent to me, so I'm assuming the order in which they're called makes no difference.Skip to navigation
What's the catch?
Speed up your site using prefetching mentions some criticisms of DNS prefetching, though no references are provided. These criticisms include the waste in bandwidth and inefficient use of client resources (particularly for mobiles) if we prefetch domain names that are not then used. It also says that DNS prefetching can skew the target site's analytics data.
This academic paper, DNS Prefetching and Its Privacy Implications: When Good Things Go Bad (PDF; 2010) highlights potential security issues around DNS prefetching. It argues that, by reading the DNS cache on a user's computer, an attacker might be able to infer details about the kinds of sites the user is visiting, and recommends disabling DNS prefetching where possible. While I can see how this might be true for prefetched domain names in the links on a page, my gut tells me that utilities as ubiquitous as Google Fonts are unlikely to reveal anything private about a user's behaviour.Skip to navigation
It looks as though DNS prefetching has both advantages and disadvantages. On the one hand, it can yield marginal gains in download performance for external assets, such as fonts, analytics, and third-party APIs. On the other hand, there are some (relatively old now) concerns that DNS prefetching is a poor use of a device's resources, and, more importantly, that there are potential security threats.
Until I've learnt more about this arcane aspect of web development, I'm happy to leave well enough alone. Perhaps this is something mortals like me were not meant to meddle with!Skip to navigation
In addition to the links above, here are some more articles I came across which discuss DNS prefetching:
- Prefetching, preloading, prebrowsing (2015) on CSS Tricks does a great job of clarifying the differences between DNS prefetching and other kinds of ‘prebrowsing’, and includes lots of further references.
- What is DNS prefetching and why it should be enabled (2010). Highlights the benefits of DNS prefetching.
- DNS prefetching in web browsers (2010) reiterates and expands on some of the security issues of DNS prefetching discussed above.
- This interesting forum discussion on the topic, Should DNS Prefetching be enabled or disabled? (2010–2012), also discusses some of the pros and cons.
Terms like ‘prefetching’ and ‘prerendering’ are used in a few other web development that are closely related to DNS prefetching, but aren't quite the same. Here are a couple to be going on with:
- Resource prefetching
- This involves preparing files such as images for rendering in advance by the browser. Since browsers are already quite clever at doing this kind of stuff, I don't think it will usually be necessary for a noob like me to worry about this. Read more about resource prefetching here.
- Page prerendering
- How about downloading a whole web page behind the scenes? That's what this badger does. Again, this is not something I'd want to dabble with lightly. Read more about page prerendering here.