17th October 2002
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.
More recent articles
- Datasette Enrichments: a new plugin framework for augmenting your data - 1st December 2023
- llamafile is the new best way to run a LLM on your own computer - 29th November 2023
- Prompt injection explained, November 2023 edition - 27th November 2023
- I'm on the Newsroom Robots podcast, with thoughts on the OpenAI board - 25th November 2023
- Weeknotes: DevDay, GitHub Universe, OpenAI chaos - 22nd November 2023
- Deciphering clues in a news article to understand how it was reported - 22nd November 2023
- Exploring GPTs: ChatGPT in a trench coat? - 15th November 2023
- Financial sustainability for open source projects at GitHub Universe - 10th November 2023
- ospeak: a CLI tool for speaking text in the terminal via OpenAI - 7th November 2023
- DALL-E 3, GPT4All, PMTiles, sqlite-migrate, datasette-edit-schema - 30th October 2023