Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Mozilla prefetching

The Mozilla Link Prefetching FAQ (via Blogzilla). Prefetching is a browser mechanism, which utilizes browser idle time to download or prefetch documents that the user might visit in the near future. Web page authors can turn on prefetching for their pages using a <link rel=“prefetch”> or <link rel=“next”> element (or the corresponding Link: headers).

While this looks like being an excellent feature, I’m slightly concerned by a couple of aspects of the implementation. Firstly, I don’t understand the necessity for following rel=“next” links as well as rel=“prefetch” ones. A “next” page does not necessarily mean the user will go there—in fact, thanks to the big accessibility drive at the moment many sites are adding rel=“next” elements that follow the logical order of the site without making it any more likely that a user will follow them. A key example of this is weblog archives—many blogs have next/prev link elements to indicate the next and previous archive pages. Few readers will ever folow them but they are there because they reflect the logical structure of the site.

My second complaint is with this part of the FAQ:

In addition to this restriction, URLs with a query string are not prefetched. This is done because such URLs often result in documents that cannot be reused out of the browser’s cache, so prefetching them often has little benefit. We found that some existing sites utilize the <link rel=“next”> tag with URLs containing query strings to reference the next document in a series of documents. Bugzilla is an example of such a site that does this, and it turns out that the Bugzilla bug reports are not cachable, so prefetching these URLs would nearly double the load on poor Bugzilla! It’s easy to imagine other sites being designed like Bugzilla, so we explicitly do not prefetch URLs with query strings.

In these days of URL rewriting and dynamically generated sites this just doesn’t make sense—what would happen if the next version of Bugzilla used URL rewriting to have “proper” links to each bug description rather than query strings? In my opinion, a better solution would be to forget about rel=“next” links entirely and instead rely only on rel=“prefetch” elements. That way authors of dynamic sites can enable prefetch if they know it will not be broken by their dynamic pages, while sites like Bugzilla that use a rel=“next” element will not be adversely affected.

This is Mozilla prefetching by Simon Willison, posted on 17th October 2002.

View blog reactions

Next: I want this book

Previous: Python e-mail features

7 comments

  1. rel=next makes W3C specs a breeze to read. rel=prefetch is a non-standard extension and is only there for people who want us to prefetch something that isn't the next page.

    Ian Hickson - 17th October 2002 15:03 - #

  2. I wasn't aware that there was a standard for rel="" attributes - however I just re-read the HTML4 links spec and spotted the link to the link-types as listed on the basic HTML data types page. Quote: "Next: Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time." In light of that I guess I can withdraw my complaints about the rel="next" part of the prefetch FAQ. I'm still not totally convinced by the "exclude things with a ? in them" part but it does seem the best solution for sites like bugzilla.

    Simon Willison - 17th October 2002 15:17 - #

  3. I agree with Simon Willison' comments about this new url prefetching mechanism. It is a nice enhancement. Soon we'll hear articles about Google giving higher rankings for url's linked to with the prefetch tag and then SEO specialists and Porn sites creating splash pages with Linkrels to get google to increase their pagerank. The truth is, on DSL I don't personally feel the need for prefetching but on dial up it can sure come in handy.

    GilbertZ - 19th October 2002 09:02 - #

  4. it would be nice if there were a way to indicate that a rel="next" link should not be prefetched. (or if the prefetchableness were indicated with an additional attribute, rather than inferred from the link relationship.) if mozilla's implementation gets widely adopted, i can foresee some sites having to remove (otherwise useful) navigational link elements to prevent invoking what would amount to a distributed denial-of-service attack on themselves.

    jim winstead - 19th October 2002 20:19 - #

  5. IMO prefetching "next" URLs should be configurable at least - some people will not want the additional transfer volume that is caused by this and in many cases, unnecessary.If you pay by transfer volume or have a limit on transfer volume you dont want the next slashdot article to get downloaded.

    JP - 10th November 2002 09:58 - #

  6. I just did a search on google and was shocked that the first site on their list asked to set a cookie (I manually accept or decline cookies)

    I wondered how the hell this happened

    Guess what google has added a prefetch feature to the first entry on its search engine results page

    What right do they have to try and get me to download any particular site?

    They don't pay for my bandwidth I do!

    The idea of prefetch may have been a good one but in reality there are too many downsides

    Dump it altogether I say. or at least TURN IT OFF BY DEFAULT and let the user decide if he wants to use prefetch

    Just consider a site wanting to cause problems for another site

    They could add hidden prefetch urls on their pages which cause an oppositions bandwidth to skyrocket.

    What about pay per click programs? Never really receiving a click but their logs show that they did so they can't dispute their fee.

    Remove Prefetch and send it to the never to be revisited bin

    Chris - 26th May 2005 01:48 - #

  7. Damn its hard to write a comment you should convert newlines by default

    Chris - 26th May 2005 01:49 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2002/10/17/mozillaPrefetching

A django site