Today I learnt about another great HTML5 feature — Prefetching, which adds the capability for the browser to load pages before a user has requested them. Definitely one for the optimisation aficionados.

In this post I’m going to explain what it is; what issues it has; and how I chose to implement it.

What is it?

The idea is that pages and/or resources that are highly likely to be required by a user are prefetched in anticipation of the user needing them. It is aimed at speeding up, and thus, improving the user experience of your site by helping to deliver what the user wants as quickly as possible.

It is an attribute that can be applied to either an anchor tag or a link tag; and interestingly it can be used to prefetch anything from a single image to a whole page. One simple use case would be to prefetch the homepage of a site on each page a user visits, e.g.

<link rel="prefetch" href=""> <!-- Firefox -->
<link rel="prerender" href=""> <!-- Chrome -->

A few cons to consider

At the moment it is not supported by all browsers. Only Firefox and Chrome do, although, they have implemented it differently with FF using a prefetch attribute and Chrome using a prerender attribute. This isn’t a huge issue but it needs to be considered because two things will have to be maintained. Users using either of these two browsers should have a better experience so can be deemed progressive enhancement and is worth using.

If you prefetch things that are rarely needed then it is a waste and a drain on your own resources and bandwidth so use sparingly. It requires some upfront work to determine what your users do on each page, where they want to go next. Similarly to making sure you choose the right thing to prefetch, make sure you don’t prefetch too many things. Again this would be pointless for obvious reasons.

It has the potential to skew your usage stats because resources are downloaded in the off chance they will be needed. The downloaded resources will show up in your stats, but there won’t be a way to tell what proportion were used by the user. Again not a huge issue but something to consider especially if your site is regularly accessed via a mobile.

These cons don’t seem to be showstoppers. They don’t outweigh the optimisation benefits a user should experience. That is an assumption I’ve made but now that I’ve added a little prefetching to this blog I should be able to report back on these shortcomings after it has been live for a while.

Implementing it with WordPress

Adding it to this wordpress blog turned out to be quite straightforward. Firstly, I needed to work out what I wanted to prefetch; or more importantly, what would be most beneficial to prefetch.

After reviewing the usage stats I concluded that people tend to do one of two things given their location.

  1. People visiting the homepage click on the most recent post.
  2. People visiting a post tend to click on the link to the main blog page.

These, therefore, are the things I wanted to optimise for. With that decided I added this snippet of code to the <head> section of my theme’s header.php file.

if (is_front_page()) {
	$args = array( 'numberposts' => 1);
	$myposts = get_posts( $args );
<link rel="prefetch" href="<?php the_permalink(); ?>">
<link rel="prerender" href="<?php the_permalink(); ?>">
<?php } elseif (is_singular()) { ?>
<link rel="prefetch" href="<?php bloginfo('home'); ?>">
<link rel="prerender" href="<?php bloginfo('home'); ?>">
<?php } ?>

It’s a very simple example but one that I think is very useful for a blog and fits a particular use case I have. I’m sure there are more interesting and complicated ways to take advantage of prefetching, and I’d be very interested in hearing about how others have used it.

Even with the limited and inconsistent browser support the prefetch attribute is a useful little capability, that is easy to implement and can be taken advantage of now to help improve the overall experience of using your site. Just remember to use it sensibly.