WebKit and Chrome prerendering

Chromium project logo

Google search result pages now trigger a prefetch and prerender of top search result links in an effort to make navigating search results as easy as changing channels on your television. If Google’s search algorithms determine there is a significant probability of user click-through on particular result they will instruct supporting browsers to preload the entire destination page including images, JavaScript, advertisements, and analytics. The page requests happen in the browser, looking like a regular webpage view with the exception of a few JavaScript variables addressable from your site’s JavaScript. Support for preloading webpages and all related assets is a feature of WebKit-based browsers released after May 2011, including Chrome 13.

  1. What’s happening
  2. How to add code to accommodate
  3. Summary

What’s happening

Any webpage may now ask supporting browsers to “prerender” another webpage to prime the browser cache and improved perceived load times. If Chrome discovers a <link> element in your document’s <head> it might trigger an unattended pageview.

A few use cases currently short-circuit the browser’s attempt to prerender the page:

  • HTTPS
  • Content requiring browser plugins such as Adobe Flash
  • <audio> or <video> content

Tracking eyeballs, not machines

So how do I track when a page is being loaded from what looks like a regular user but is really a background process of the browser? The prefetch features of WebKit also support the in-progress page visibility API. JavaScript running on your pages can check the current visibility of the document and attach new event to take action if that state changes.

var isVisible = false;
if ( document.webkitVisibilityState === undefined || document.webkitVisibilityState === "visible" ) {
  visibilityFunction();
} else {
  document.addEventListener( "webkitvisibilitychange", visibilityFunction );
}

You may view a full example using the jQuery JavaScript framework. You may test your page’s prerender behavior on a page created by the Chromium project.

A webpage has three visibility states: hidden, prerender, and visible. A tab opened behind the current tab is hidden. A page requested by the browser but not yet shown in the browser UI. Standard navigation and viewing is visible. Browsers not yet supporting the Web Visibility API return an undefined state when your script attempts to access the property. If you are tracking a visitor’s first interaction with a page you are probably interested in the visible state. Inside your visibility function you will want to check the visibility state and call your functions of interest.

Summary

What looks like a real pageview from a modern browser might be a browser downloading your page resources in the background before possibly being presented to an actual visitor. Websites that care about separating eyeballs from machines should add new JavaScript to their pages to create awareness of the current loading state. This new prerender behavior is enabled by default in Chrome 13 and will become more common as WebKit-derived browsers or competitors enable similar functionality to improve perceived page load times.

1 comment

Commentary on "WebKit and Chrome prerendering":

  1. Andrey Sitnik on wrote:

    Check property with vendor prefix and set event listener is not useful code. It will be better to use Visibility.js library with syntax sugar for this (wrap under Page Visibility API): Visibility.notPrerenderer(function() { /* do some stuff */ })