Prerender and Prefetching preload your pages improving UX
On Monday June 25, 2012 Google offered us a new perspective and renewed information on a striking and very little extended technique to improve usability and loading speed from its blog for webmasters, in this Google article the concept of prefetching is deepened and reviewed, shared with Mozilla, although from the original idea has been derived a technique that Google shares with the world and that is based more on its own technical and infrastructural capabilities and strategic plans than on common agreements with W3C or other entities that exercise influence on the development of the Internet and the www.
Like everything, the pre-rendering has good things and bad things, it is advisable to read carefully before getting down to work.
Web Developer’s Guide to Prerendering in Chrome
Prerendering is an experimental feature in Chrome (versions 13 and up) that can take hints from a site’s author to speed up the browsing experience of users. A site author includes an element in HTML that instructs Chrome to fetch and render an additional page in advance of the user actually clicking on it.
As a web developer, you may be interested in triggering prerendering or, much more likely, in detecting when your site is being prerendered.
Overview of prefetching and prerendering
Because the web is a distributed system, it may take some time between when a user clicks on a link and when the page content is loaded. This problem becomes especially noticeable in sites that include JavaScript, plugins, and other referenced materials like media or style sheets.
In some cases it’s possible to know where a user is likely to click next—for example, when a user is reading a multi-page article, it’s likely he will click on the “Next page” link. In these cases, it would be nice if the browser could begin loading the page before the user even clicks, so that when he does click the page is already on its way to being ready to view. This is the main insight behind both prefetching and prerendering. The concept of prefetching is included in the HTML5 spec.
Prefetching is a feature that is currently implemented in Firefox (learn more about Firefox’s prefetching). It allows site authors to include a tag in their HTML that instructs the browser to begin fetching a given URL. When it encounters the tag, the browser fetches the top-level resource at that URL (most often an HTML page). Prefetching, however, often does not lead to user-noticeable speed-ups because most of the content is in sub-resources, such as JavaScript, CSS, and media files. Also, in some cases the sub-resources aren’t even part of the HTML as provided by the server, and are only inserted via scripts when the page loads.
Prerendering extends the concept of prefetching. Instead of just downloading the top-level resource, it does all of the work necessary to show the page to the user—without actually showing it until the user clicks. Prerendering behaves similarly to if a user middle-clicked on a link on a page (opening it in a background tab) and then later switched to that tab. However, in prerendering, that “background tab” is totally hidden from the user, and when the user clicks, its contents are seamlessly swapped into the same tab the user was viewing. From the user’s perspective, the page simply loads much faster than before.
Web developers can trigger prerendering as described below. Beginning in Chrome 17, Chrome itself will initiate prerendering in some cases, based on the user’s interactions with the address bar.
Triggering prerendering
Deciding if prerendering is for you
Prerendering is an advanced, experimental feature, and mis-triggering it can lead to a degraded experience for your users, including increased bandwidth usage, slower loading of other links, and slightly stale content. You should only consider triggering prerendering if you have high confidence which link a user will visit next. For example, prerendering could potentially be a good idea for a “Next page” link in an article. Providing prerendering hints is not appropriate for the vast majority of sites and use cases.
Syntax for triggering prerendering
Prerendering in Chrome is triggered by a tag in HTML, similar to how prefetching is triggered in Firefox. (Note, however, that unlike in Firefox the meta-http and HTTP header triggering methods are not supported at this time.)
You can trigger prerendering by inserting a link element with a rel of “prerender”, for example:
When Chrome encounters the element it will consider prerendering the linked page. This may happen when parsing the page, or later if the link element is dynamically inserted into the document via JavaScript.
We use the rel of ‘prerender’ instead of ‘prefetch’ to denote that this is an experimental implementation and ensure that users of prefetch do not accidentally trigger prerendering without understanding how it differs from existing prefetch implementations.
Remember that the tag is just a hint to Chrome that it may want to prerender—it does not guarantee that prerendering will actually happen. Some of the reasons prerendering might not happen:
Note: This is not an exhaustive list. Last updated 6/13/11.
- The user is using a version of Chrome where prerendering is not enabled by default.
- The user has disabled prerendering by unchecking “Predict network actions to improve page load performance” in Settings.
- Another page is already being prerendered. Chrome will only prerender at max one URL per instance of Chrome (not one per tab). This limit may change in the future in some cases.
- There are multiple prerender directives on the page, in which case which prerender directive is taken and which is ignored is undefined (depending on the timing of when the directives were encountered).
- Chrome encountered another prerender directive within the last 500 ms.
- The user is browsing in an incognito window
- The prerender is aborted based on a situation caused by the receiving page. See “Situations in which prerendering is aborted”.
See the Debugging prerendering section for help analyzing whether prerendering occurred in a given instance.
To prevent stale content being presented to the user, pages that are successfully prerendered will be evicted after 30 seconds if the user has not yet clicked the link. This limit may change in the future.
Pages that are prerendered will not show up in a user’s history unless the user actually visits the page. However, cacheable resources from an unvisited page that was prerendered may remain in the cache, and changes prerendered sites make to cookies will persist.
Although prerendering has been carefully designed with security in mind and Chrome will abort prerendering in scenarios where a malicious site is detected, abuse scenarios do exist, just as they do with established technologies like iframes.
Detecting when your site is being prerendered
Even if you do not proactively trigger prerendering yourself, it is still possible that another site will instruct Chrome to prerender your site. If your page is being prerendered, it may or may not ever be shown to the user (depending on if the user clicks the link). In the vast majority of cases, you shouldn’t have to do anything special to handle your page being prerendered—it should just work.
If you do need to know that your site is being prerendered (for example, you don’t want an image slideshow to start cycling until the user actually views the page), the experimental Page Visibility API provides a convenient way to detect those cases and behave appropriately.
Note: Chrome does not pass any distinguishing headers when prerendering occurs. Because the majority of prerenders convert into real pageviews, the Page Visibility API is the only way to correctly account for prerenders. When the page is shown to the user, no new requests are sent by Chrome, although you could create a script that uses the Page Visibility API to trigger a new request.
If your site includes a third-party script for analytics or advertising, in many cases you shouldn’t have to make any modifications to your site—the third party will simply modify the script they provide slightly to make use of the Page Visibility API. You should contact the third party directly to see if their scripts are prerender-aware.
You can test how your page behaves when prerendered using this simple test page.
Situations in which prerendering is aborted
In some cases while prerendering a site Chrome may run into a situation that could potentially lead to user-visible behavior that is incorrect. In those cases, the prerender will be silently aborted. Some of these cases include:
Note: This is not an exhaustive list. Last updated 11/10/11.
- The URL initiates a download
- HTMLAudio or Video in the page
- POST, PUT, and DELETE XMLHTTPRequests
- HTTP Authentication
- HTTPS pages
- Pages that trigger the malware warning
- Popup/window creation
- Detection of high resource utilization
- Developer Tools is open
Plugins such as Flash will have their initialization deferred until the user actually visits the prerendered page.
Debugging prerendering
Prerendering is designed to be nearly invisible to the casual user—sites just load faster in some cases. Chrome may decide to either not initiate or abort a prerender for any number of reasons, which means that for developers it can sometimes be difficult to tell if prerender happened in a specific case. The following section explains how to determine whether prerendering was used for a page.
You also have the option of disabling the Chrome 17+ feature that can initiate prerendering based on user interaction with the address bar. To disable this type of prerendering, start Chrome with a command-line flag of --prerender-from-omnibox=disabled.
Checking whether prerendering was used for a page
The page load speed of a page alone is not necessarily a foolproof indicator of whether prerendering happened.
To check whether prerendering is happening for a page:
- Open Chrome’s Task Manager.
- Load the page that includes the prerender hint.
- Check for a new line starting with “Prerender: ” that shows a special icon (see the following screenshot). If you see such a line, prerendering is happening for that page.
Starting with Chrome 14, the net-internals tab includes more detailed information about prerendering. You can get to the net-internals tab by copying and pasting the following URL into the Chrome address bar:
chrome://net-internals/#prerender
Ensuring you have prerender turned on
Prerender is currently enabled for many users of Chrome 13 by default. However, there are some cases where prerender may be disabled. If the steps listed in Checking whether prerendering was used for a page show that prerendering is occurring, then prerendering is enabled for you.
This simple test page will alert you if prerendering appears to be disabled for you.
To completely ensure that prerendering is enabled:
- Visit Chrome’s settings and ensure that “Predict network actions to improve page load performance” is checked (it is checked by default).
- Start up Chrome with the
--prerender=enabledcommand-line flag.
Want to know more about prerendering?
Participate in the prerender discussion group at http://groups.google.com/a/chromium.org/group/prerender/topics.
Last updated March 30, 2012.
