Check this out!

<link rel="next" href="page2.html">

With HTML5, that's all you've got to do to preload a page. Hat tip to Conner over at keyboardy for pointing this out. It's like cheating on behalf of your users, to get them faster page loads. Of course, this is what "web accelerators" have done for years, so it's good of the W3C to add this feature to the spec.

He mentions a few example use cases to get the creative juices flowing, and more importantly, points out that this technique can dramatically change your server stats. So, if you're using a package to analyze web server logs, you'll need to account for pages being preloaded. Right now only Firefox supports this next/preload feature, and it sends a custom header with the request. I imagine other browser makers will too. Still -- use of this feature could mean all old and unmaintained stats packages are useless -- aren't you glad you use open source and can edit the package to account for the new header? :D

One thing that he didn't mention is the implications for your server. Let's say every page has a single "next" page referenced -- just one and no more. If you've got a bounce rate of 50%, you'll be serving a lot of pages that no one will ever see. Static sites don't have to be concerned -- serving flat files is a no-brainer. But, if you've got a dynamic site, lots of uncached data, and a service that's routinely around 60-70% capacity on a normal day, you could overload a web or DB server. Put more than one prefetch instruction per page, and the load goes up even more. Ops teams take note -- a bad template or front-end decision could easily double your traffic overnight, without the upside of gaining additional users. This potential for crashing means we could be talking about the single most dangerous HTML tag  -- worse than <blink> and <marquee>.

Edit: mcotton, a Hacker News commenter pointed out that a nice solution is to configure your server to ignore requests with the preload header if they are above a certain load.