Pretty Fetching

So far the only link pre-fetching I’ve observed from Google has been of www.stanford.edu. This is terribly funny, actually, since the pre-fetching of this page doesn’t speed things up. Here’s why:

HTTP/1.x 200 OK
Date: Thu, 31 Mar 2005 17:28:48 GMT
Server: Apache
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

Stanford does not provide enough information with the prefetched response for Mozilla to use the cached version, or for Mozilla to ask for Stanford to return the page only if it has been modified. What we should see are some more headers, specifically Last-Modified: and/or Etag:, so that we can make a request to which the server can respond HTTP/1.x 304 Not Modified.

So, even though Mozilla has prefetched the page into local cache, it still makes an HTTP GET for http://www.stanford.edu/, to which Stanford, smart people that they are, respond “OK.”

Now, here’s the really funny part: pre-fetching is broken in Firefox’s default configuration anyway.

MovableType, and TypePad, also enable pre-fetching, by the use of a link rel="next" element. Since typepad.com does not always emit Last-Modified: and Etag: headers, look at my test case here. What we should see is that the next page is pre-fetched, with an HTTP/1.x 200 OK response. Then an actual click should make the same request, but including If-Modified-Since: and If-None-Match: headers, with a HTTP/1.x 304 Not Modified response.

Instead we see Damn. My test case works. I swear it wasn’t working before. Anyway, it doesn’t work with MovableType.

1 Comment

  1. Pingback: Cox Crow

Comments are closed.