Jump to content

Link prefetching

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Cloud200 (talk | contribs) at 21:34, 19 March 2016 (→top: I don't think these issues are still valid). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Link prefetching is a 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 was 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. It is most effective in cases where the content provider may be reasonably certain which link or links the user is going to visit next.

Link prefetching is included in a WHATWG Living document and the W3C Candidate Recommendation for HTML5. It is partially implemented in Mozilla Firefox, and a different but related concept is implemented in Google Chrome. Internet Explorer 9 and newer instead use DNS prefetching to improve the user experience, with newer versions providing support for other types of prefetching.

HTML5 prefetching

Below are various methods that enable different types of link prefetching in supported browsers using HTML5 markup language to display a given link:

  • Standard link prefetching (executed by most modern browsers):
    <link rel="prefetch" href="http://www.example.com/">
  • DNS prefetching (Mozilla Firefox, Google Chrome, and others):
    <link rel="dns-prefetch" href="http://example.com/">
  • Prerendering (Google Chrome, Internet Explorer and others):
    <link rel="prerender" href="/page/to/prerender">
  • Lazy-load (Images) (Internet Explorer):
    <img src="image.jpg" lazyload>

The prefetch hints can be also sent in Link[1] HTTP headers, for example: 

Link: <//pagead2.googlesyndication.com>; rel=dns-prefetch, </js/bootstrap.min.js>; as=script; rel=preload, </adsense.iframe.html>; rel=prerender, </css/bootstrap.min.css>; as=style; rel=preload

Two W3C standards discuss different forms of prefetch:

  • Link preload[2]
    • explicit preloading of resources such as JavaScript, CSS, images and web fonts
  • Resource hints[3]
    • less imperative hints for resources mentioned above as well as DNS name prefetchig, TCP pre-connecting, page pre-rendering

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

Browser Prefetching Supported
Standard link prefetching DNS prefetching Prerendering Lazy-load (Images)
Android browser Yes[4] No[4] No[4] No
Chromium Yes[4] Yes[4] Yes[4] No
Google Chrome Yes[4] Yes[4] Yes[4] No
Internet Explorer Yes[5] Yes[5] Yes[5] Yes[5]
Mozilla Firefox Yes[4] Yes[4] No[6] No
Opera Yes[4] No[4] No[4] No
Safari No[4] Yes[4] No[4] No

Historical

Modern browsers

  • Mozilla Firefox supports DNS prefetching, as of version 3.5.[8]
  • Google Chrome supports prefetching of linked web content by "prerendering", as of version 11.[9]
  • Internet Explorer supports prefetching of IP addresses by "DNS prefetching", as of version 9.[10]
    • As of version 11, Internet Explorer supports the following set of features to expand its prefetching capabilities: "prerender", "dns-prefetch" and "lazyload" (images only).[5]

Sites using prefetching

  • Google is the most 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.
    • Specifically, Google implemented "Google Instant Pages" in August 2011 which takes advantage of the aforementioned feature, predictive search completion, and preloading search results as the user types in order to improve the performance of the search engine.[11]
  • Bing has employed the use of prefetching and preloading since the release of Internet Explorer 11 (October, 2013).[5]

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.[12] However, it's not uncommon for website operators to use these requests 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 containing these types of links, (whilst using a browser which employs an indiscriminate link prefetcher), might find that they have been logged out or that their files have been deleted.[13]

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.

In the case of mobile devices or for users with a limited bandwidth allowance, prefetching may result in an unnecessary costly drain on limited bandwidth.

In the case of prerendering, Google warns that improper use may result in the aforementioned increased bandwidth usage, slower loading of other links, and slightly stale content.[9]

See also

References

  1. ^ "Web Linking". RFC 5988. IETF. Retrieved 2016 March 19. {{cite web}}: Check date values in: |accessdate= (help)
  2. ^ "Preload". w3c.github.io. Retrieved 2016-03-19.
  3. ^ "Resource Hints". w3c.github.io. Retrieved 2016-03-19.
  4. ^ a b c d e f g h i j k l m n o p q "Prebrowsing". Steve Soulders. 2013-10-07.
  5. ^ a b c d e f "Getting to the Content You Want, Faster in IE11". IEBlog, Microsoft. 2013-12-04.
  6. ^ "Bug 730101 - Implement prerendering in Firefox". Steve Soulders. 2014-10-18.
  7. ^ Fisher, Darin; Saksena, Gagan. "Link Prefetching in Mozilla: A Server-Driven Approach" (PDF). Retrieved 2014-05-09.
  8. ^ "Controlling DNS prefetching". Retrieved 2014-05-09.
  9. ^ a b "Web Developer's Guide to Prerendering in Chrome". Retrieved 2014-05-09.
  10. ^ "Internet Explorer 9 Network Performance Improvements". Retrieved 2014-05-09.
  11. ^ "About Google Instant". Retrieved 2014-05-09.
  12. ^ Fielding, Roy; Gettys, Jim; Mogul, Jeffrey; Frystyk, Henrik; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (June 1999). "Safe Methods". Hypertext Transfer Protocol—HTTP/1.1. Network Working Group. IETF. p. 50. sec. 9.1.1. doi:10.17487/RFC2616. RFC 2616. Retrieved 2009-12-16.
  13. ^ various (2009). "Mouseover Prefetch?". Gervase Markham, MozillaZine. Archived from the original on 2009-12-16. Retrieved 2009-12-16.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Link_prefetching&oldid=710921782"