Link prefetching

Link prefetching is a proprietary syntax to give web browsers a hint about documents that it should pre-fetch because the user might visit them in the near future. It is proposed as a draft internet standard by Mozilla. A web page provides a set of prefetching hints to the browser, and after the browser is finished loading the page, and after an idle time has passed, it begins silently prefetching specified documents, storing them in its cache. When the user visits one of the prefetched documents, it can be served up quickly out of the browser's cache.

As prefetching is an Internet Draft standard, examples of prefetching can be divided into standard compliant and non-compliant:

HTML5 prefetching

Prefetching is not currently explicitly defined by any accepted standards, but Mozilla have announced work on an Internet Draft, that will match the implementation in Firefox.^[1]

<link rel="prefetch" href="http://www.example.com/">

Other prefetching

It is possible for implementations to prefetch links even when they are not specified as prefetch links.

• Fasterfox has an option to enable the prefetching of all page links by the browser.

Browser support

• iCab was the first browser (February 2001 or earlier ) to support prefetching
• Mozilla Application Suite and its derivatives (Firefox etc.) - the first browser to support prefetching per the Internet Draft.^{[citation needed]}
• Browsing using a Google Web Accelerator (discontinued product, may technically be called precaching)
• The Blue Coat proxy appliance is known to use non compliant prefetching
• Internet Explorer supports prefetching of IP addresses through DNS, as of version 9: Page-initiated Pre-resolution

Sites using prefetching

Notable sites include:

• Google is the first well-known website that takes advantage of this feature so as to improve the user experience. If the first hit is considered very probable to be the desired hit, it is assigned as a prefetchable link.

Issues and criticisms

An issue inherent to indiscriminate link prefetching involves the misuse of "safe" HTTP methods. The HTTP GET and HEAD requests are said to be "safe", i.e., a user agent that issues one of these requests should expect that the request results in no change on the recipient server.^[2] However, it's not uncommon for website operators to use these request outside of this constraint. Plain hyperlinks (which almost universally result in GET requests) are often used to implement logout functionality and account verification, e.g., when a user completes an account creation form, and an automated service sends a verification e-mail to the user's given e-mail address. Similarly, it is entirely possible for a hosting service to provide a Web front end to manage files, including links that delete one or more files. Users who visit pages with these types links while an indiscriminate link prefetcher is employed might find that they are logged out or their files have been deleted.^[3]

Additionally, there are a number of criticisms regarding the privacy and resource usage implications of link prefetching:

• Users and website operators who pay for the amount of bandwidth they use find themselves paying for traffic for pages the user might not actually visit, and advertisers might pay for viewed ads on sites that are never visited.
• Web statistics such as browser usage, search engine referers, and page hits may become less reliable due to registering page hits that were never seen by the user.
• Users may be exposed to more security risks - by downloading more pages, or from un-requested sites (additionally compounded as drive-by downloads become more advanced and diverse).
• Users may violate acceptable-use policies of their network or organisation if prefetching accesses unauthorised content.

See also

• Prefetching

Notes

External links

• Mozilla Link Prefetching FAQ
• Google Help: Search Features
• Test for Prefetch support
• Prerender and prefetch support in Internet Explorer 11