The concept of prefetching is pretty simple. We often know about resources the browser is likely to need before the browser does. Prefetching involves either giving the browser hints of pages or resources it is likely to need so that it can download them ahead of time, or actually downloading resources into the browser cache before needed so that the overhead of requesting and downloading the object can be preemptively handled or done in a non-blocking way.
There are many ways to prefetch content, but here are 3 simple options.
DNS Prefetching
DNS is the protocol that converts human readable domains (mysite.com) into computer readable IPs (123.123.123.123). DNS resolution is generally pretty fast and measured in 100’s of milliseconds, but because it must happen before any request to the server can be made it can cause a cascade effect that has a real impact on the overall load time of a page. Often we know about several other domains that will need to be loaded for resources later in the page or user session, such as subdomains for static content (images.mydomain.com) or domains for 3rd party content. Some browsers support a meta tag that identifies these domains that need to be resolved so the browser can resolve them ahead of time. The tag to do this is pretty straight forward:
<link href="//my.domain.com" rel="dns-prefetch" /> <link href="http://my.domain.com/" rel="prefetch" /> <!- IE9+ ->
Adding this tag causes the browser to do the DNS resolution ahead of time, instead of waiting until a resource requires it later. This technique is probably most valuable to preload DNS for content on other pages on your site that visitors are likely to go to. This feature is supported in Chrome, Firefox, and IE9+.
Although shaving a few hundred milliseconds might seem trivial, in aggregate this can be a measurable gain. It’s also a safe optimization and easy to implement. I was curious to see how often this technique is used, so I crawled the top 100K Alexa sites. It turns out only 552 sites (0.55%) are currently using DNS prefetching. This is a cheap win, and something more sites should leverage.
Resource Prefetching
Images make up a large portion of the overall bytes of many major websites today. Often the overhead of making the requests and downloading images can have a significant performance impact. In many cases, though, the site developer knows when an image will be needed that won’t be detected early by the browser, such as an image loaded from an ajax request or other user action on the page. Resource prefetching is when you load an image, script, stylesheet, or other resource into the browser preemptively. This is most often done with images, but can be done with any type of resource that can be cached in the browser.
Of the three techniques I’m covering here, this is by far the oldest and the most used. Unfortunately I can’t give a concrete number about adoption because there are too many ways to implement this to detect in my Alexa crawl. Still, many sites don’t properly leverage this technique and even just preloading a few images can make a huge difference for the user experience.
Page Prefetching / Prerendering
Page prefetching is very similar to resource prefetching, except that we actually load the new page itself preemptively. This was first made available in Firefox. You can hint to the browser that a page (or an individual resource) should be prefetched by including the following tag:
<link rel="prefetch" href="/my-next-page.htm">
In the case of prerendering, the browser not only downloads the page, but also the necessary resources for that page. It also begins to render the page in memory (not visible to the user) so that when the request for the page is made it can appear nearly instantaneous to the user. Prerendering was first added in Chrome. You can hint that a page should be prerendered by including the following tag:
<link rel="prerender" href="http://mydomain.com/my-next-page.htm">
This technique is by far the most controversial and the riskiest of the three. Prerendering a page should only be done when there is a high confidence that the user will go to that page next. The most well known example of this is Google Search, which will prerender the first result of the page if the confidence is high enough. I found only 95 examples of this in my crawl of the Alexa Top 100k sites. Although this technique is clearly not for every use case, I think many more sites could leverage this to improve the user experience.
The Downsides
Prefetching in general is often a controversial topic. Many people argue that it is not efficient and leads to a waste in bandwidth. It also uses client resources unnecessarily (most notably on mobile devices). Also worth mentioning is that in some cases prefetching or prerendering of pages can have adverse effects on analytics and log tracking since there is no obvious way to discern a user visiting the page (and seeing it) or simply the browser prerendering without the user’s knowledge.
Conclusion
Despite all of these cautions, prefetching can be a huge win. The fastest request is always the one we never have to make and getting as much into the cache as possible is the best way to make that happen. By making these expensive requests when the user is not waiting on them, we can greatly improve the perceived performance of even the slowest sites on the slowest networks. If you’re not already doing so, it’s worth trying these techniques on your site. The results will vary, so be sure to use Real User Measurement (e.g. Torbit) to find out how much of an improvement prefetching makes for you.