HTML5 Link Prefetching
One effort shared by both browsers and developers is making the web browsing experience faster. There are many common-known ways to keep your websites fast: using CSS sprites and image optimization, using .htaccess to set file headers for longer caching, javascript file compression, using CDNs, and so on. I've even detailed some of the website optimization efforts used on this website. Firefox introduces a new strategy for website optimization: link prefetching.
What is link prefetching? From the MDN:
Link prefetching is a browser mechanism, which utilizes browser idle time to download or prefetch documents that the user might visit in the near future. A web page provides a set of prefetching hints to the browser, and after the browser is finished loading the page, it begins silently prefetching specified documents and stores 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.
Simply put: the browser downloads designated documents (pages, images, etc.) the user will likely visit after the current page. It's even super easy to implement!
HTML5 Link Prefetch Tag
<!-- full page --> <link rel="prefetch" href="https://davidwalsh.name/css-enhancements-user-experience" /> <!-- just an image --> <link rel="prefetch" href="https://davidwalsh.name/wp-content/themes/walshbook3/images/sprite.png" />
HTML5 prefetching is done via the LINK tag, specifying "prefetch" as the rel and the href being the path to the document. Mozilla also answers to a few differently named LINK rel attributes:
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css" /> <link rel="next" href="2.html" />
HTTPS fetches are also supported.
When to Prefetch Content
Whether prefetching is right for your website is up to you. Here are a few ideas:
- When a series of pages is much like a slideshow, load the next 1-3 pages, previous 1-3 pages (assuming they aren't massive).
- Loading images to be used on most pages throughout the website.
- Loading the next page of the search results on your website.
Preventing Prefetching
Firefox allows you to disable link prefetching with the following setting snippet:
user_pref("network.prefetch-next", false);
Prefetching Notes
A few more notes about link prefetching:
- Prefetching does work across domains, including pulling cookies from those sites.
- Prefetching can throw off website statistics as the user doesn't technically visit a given page.
- Mozilla Firefox, currently the only browser to support prefetching, has actually supported prefetching since 2003.
So what do you think? Using spare time to download extra files seems both dangerous and exciting. Let me know your thoughts!
Wow! The idea of prefetching links has never crossed my mind before reading this, but it seems like a great idea. I’ll have see if there are a few good places to implement this on my site. Thanks David!
MSIE has had something similarly helpful since IE 5.0
http://blogs.msdn.com/b/ieinternals/archive/2009/07/20/using-post_2d00_check-and-pre_2d00_check-cache-directives.aspx
I think its a very good idea, but we need to know when is a good place to implement. thank you for the article. If i use prefetching i let u know.
My only concern is the extra hit on your own servers. But there are plenty of places its worth using – like a checkout user journey. Or for the first few full size images on a page using a light box.
Maybe it’s in the image I cannot see, but there also is rel=”prev” and rel=”next” that can be related. Search results can use them. I’m not sure how to mix both rel=”next” and rel=”preftech”. Should we use 2 with the same href?
This could do image preloading for image hover states and such that aren’t sprite-mapped rather than using JS. Now if only all the browsers had this functionality.
I did not know about prefetching, and it is very easy to see. thanks for sharing!
I’m not clear about what you say on sit statistics: sure the links are downloaded in the background but they have to be downloaded some way, so the browser logs should have them and the site statistics should be correct. Am I wrong somewhere?
I think prefetching is a great way to go but like most things on the web there needs to be a crossbrowser standard. Its a shame that it messes with statistics, maybe you could detect if a load is a prefetch serverside and let your analytics js take it into account and wait for the page to be rendered before counting.
Great article! heard about it before but never gone to the extent of implimenting it. Think its time to do it now.
I think the idea behind this is pretty solid. Though, like Joe says, it’s a real shame that it can alter the analytics. I could also see this being misused by having a browser prefetch every active link on the page. What kind of effect would this have on the browser cache? Are the prefetched files recorded in the cache as a visited page? Can a page prefetch malicious software/files? That would be a concern for me.
I have the same concerns as Jared. How are people going to abuse this? Because they will.
If I understand the mechanism correctly, prefetching shouldn’t affect analytics that are based on Javascript, such as Google Analytics. If you tell the browser to prefetch a certain web page, it will send a request for that page: it shouldn’t execute the Javascript it contains until the user actually views that page, so GA and similar analytics schemes should be unaffected.
Analytics tools that process server log files will be affected, because there’s no way for them to distinguish between a prefetch and any other kind of request, and there’s no way to know whether a prefetched page was subsequently viewed or not.
On another note, because prefetch can work cross-domain, there are potentials for abuse. ‘Prefetching’ malware is one option; so too is using prefetch for click-fraud or for scamming voting pages. I’m sure the creative minds behind Internet Evil could come up with other applications. On the other hand, I doubt that there’s anything that you can do with prefetch that you couldn’t also do with hidden IFRAMEs, Javascript, etc.
Imagine how awful it would be if those pages got added to history too. You could add a bunch of porn sites to the user’s history!
My only concern would be smart phone users with limited data plans. But I suppose you could sniff them out. In addition, I wonder, if you were to add some form of hash to differentiate these prefetched links from normally hit ones, that might prevent false analytics. Thoughts?
This strikes me as something that has some good uses in theory and in the right hands… but it also seems like something that can be easily abused by people looking to force people to open links and download potentially malicious content without their consent. I’ll be interested to see what happens with this.
It’s up to the browser to decide wether to prefetch the links that the page suggests.
A browser on a mobile device should be capable of deciding not to prefetch the links if bandwidth is metered and a desktop browser should be able to risk asses links to a remote domain.
It’s nice of Mozilla to give us the option of providing a faster experience to its users.
“using CSS sprites and image optimization”
Or not using images :) now with css3, there is lot of way to not using images anymore.
Otherwise, That’s a great way to smartly pre-caching webpage like blog next page .
Thanks for the article
Regards, gren
Can you use pre-fetching to go to affiliate links or competitor paid ads?
Never used it or seen it in action, but it should definitely be limited to destinations in the same domain, or domains with corresponding cross-domain policy files.
Wonder how easily this could be shimmed with some Moo hackery…
wicked awesome! i’m going to go ahead and say that this should go ahead and be the default standard for print stylesheets. i was a fan of placing them after the closing body element and/or adding them after page load, however this looks much easier and is also not relying on JavaScript and/or breaking separation of concerns.
per usual, you rule dude. thanx!
Huh, good stuff. I’ve read several articles on HTML5 and I haven’t even heard prefetching mentioned yet. Odd!
Does anyone know how to actually test how/what the prefetching is requesting/retrieving? As far as I can tell, neither Firebug’s Net tab or the LiveHTTPHeaders extension ‘see’ the prefetch request, so it’s hard to figure out just what resources have been pre-loaded.
Matthew, check out Fiddler:
http://www.fiddler2.com/fiddler2/
It’s an interesting capability, and I could see many uses for it. But what if you’re streaming music, and don’t want to use up additional bandwidth? Can the user turn it off?
Is this similar to or the same as DNS prefetching, i.e. it’s not HTML5 specific, but browser specific. I’ve heard that Chrome and Safari and others are doing this and it doesn’t require the rel=prefetch tag to be in the code. The browser just prefetches on its own. And if so, is this type of activity still ignored by javascript based analytics (such as google analytics)?
Howdy! I could have sworn I’ve been to this website before but after reading through some of the post I realized it’s new to me. Anyways, I’m definitely delighted I found it and I’ll be bookmarking and checking back frequently! Cheers!
Nice article, Chrome now includes this link prefetching via the rel of “prerender” rather than “prefetch” so you need to include both if wishing to allow prefetch on both browsers. Works great if you prefetch the home page – where most visitors go to after entering the site via a search engine.
IE9 only supports DNS prefetching (via “prefetch” rel too) but it’s for DNS, not link prefetching like FF/Chrome so really doesn’t make much difference.
The code for WordPress sites is a bit different – included examples at http://techlogon.com/2011/10/22/speed-up-a-wordpress-blog-with-prefetch
I made some tests and that’s a bit crazy but it doesn’t seem to work.
Chrome’s inspector display my ressources in red in the timeline with a “(canceled)” status.
Firefox doesn’t care.
The MDN FAQ about prefetching (https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ) suggests to test if our browser supports link prefetching and points to this page :
http://browserspy.dk/prefetch.php
Neither Chrome nor Firefox support prefetching, according to this test (tested with OS X ML and Windows 8).
So I’m wondering what happens. Is my code and the prefetch test buggy ? Does it work for you ?
Hello David,
Link prefetching concept is amazing and I never know about it before. Certainly it help but one should clearly know where to use. I will surely use it when I think there is a need to do so.
Thanks for posting.
I think Google Chrome also supports prefetching. https://developers.google.com/chrome/whitepapers/prerender
If someone needs information about prefetching in german
I wrote about it her: http://www.t-dial.in/2013/04/link-prefetching-dns-prefetching.html
this is similar to have iframes loading the next page.
When I view our Network response in Chrome, I see all our prefetched files being canceled and I’ve been told,
“They’re broken in Chrome (due to a Chrome bug) but they’re mostly harmless.”
I can’t find any documentation supporting this claim. Does Chrome currently have prefetching bugs that are poorly documented?
So I was just racking my brain for the last 2 hours on why my $_SESSION data had been messing up in FF but not in Chrome.
Preamble: On my site I use the rel=”prev/next” ‘s
So, I just put in some code within the search results of my site. It grabs the ID’s from each record (from the database) and then stores them in a session variable. I do this so that when a user clicks on a record so go to the data page, the session variable containing the ID’s will then act as a mini pagination system on that data page (Prev / Back to Results / Next).
Anyway, I was noticing that in FF the session variable was being set with the records from page 2 of the search results because it was pre-fetching page 2 due to
I know they mean well, but I think they should have just left the rel prev/next alone and stuck with just the rel=”prefetch” so that we can control what needs to be pre-fetched specifically.
I know it can be disabled at the browser level, but that doesn’t help me at all.
Guess I could just write a browser detection script where if browser is FF hide the but I hate doing that kind of thing.
Hope this post helps somebody in the future. I was banging my head off the wall for at least 2 hours there.
Internet explorer 11 is supporting prefetch atribute
http://msdn.microsoft.com/en-us/library/ie/dn265039%28v=vs.85%29.aspx
Thank you for this! I’ve had some insanely annoying problems on a site I’m developing, functions from other pages kept running inexplicably. I randomly heard about prefetching earlier today, and sure enough, it was the problem. Your code fixed the problem. You would think the server would know not to run scripts when it’s a prefetched page, but apparently not!
This can really improve user experience for the home pages. Usually, developers include big combined js files for download of home page (to avoid multiple hits and reduce dns and connection times). Instead, we could just add the basic js code for the home page and then use prefetch to download the remaining js and images for next pages.
Think its an awesome idea, but already thought about it and working on a better way of improving it,Implementing it based on the user’s site navigation histories, knowing what links they will likely click and not just pre-fetching any link. Nice Idea though since its improves Users Experience…
Old post but I’m looking for a JavaScript way to invoke this.
HTML5 audio player that supports playlists. What I want to do, of course after determining media type the browser can play of course, is when an audio starts playing – tell the browser the next audio in the playlist so during idle time it can start downloading it to cache making advancement through the playlist instant.
Is there a way via via JS to say “Hey Browser, if you aren’t too busy, would you mind fetching nextsong.opus?”
Awesome article! Is there a way to control the amount of time the resource is stored in HTTP cache from client side? I read that we can set cache-control headers as part of response to do this, but was wonder if we could do this from client side itself.