Current mood:

tired

Prefetching CSS, JS and JPG can save you seconds
I spent a fun couple of hours tonight tinkering with link prefetching and preloaded Javascript on wikifur.com. The idea is to use the time between the user seeing the front page and them clicking a language to download a few of the files we know they'll need - rather than having to load the page, figure out what other files are needed, then open connections and load them while the user waits.

In ideal circumstances, fr/de/ru/es.wikifur.com et. al. now display in under half a second for users who've never visited before if they go via the front page. Firefox users avoid the distraction of the header loading in the background, too, which can make it seem slower than it is.

Here's how it works (refresh and view source on wikifur.com to see the actual HTML):
* The CSS and JS files are shared; we know the files on pool.wikifur.com will be needed if the user enters a wiki.
* We tell the browser to preload the CSS files and header background when it gets the time with link rel="preload". This works only for Firefox, but 50% of our readers use it. It does this after everything else.
* We load the Javascript files at the end of the front page, hopefully resulting in both the source and compiled bytecode in the cache. I've no idea if it actually does the latter, but it would make sense. This caches for all browsers, and should not delay the user as the JS is loaded after everything else.
* Loading these files also caches their DNS entries and opens up connections to sites that can be needed later if it needs to load more files (it almost certainly will from two of them)

I thought of adding DNS prefetching until I realized it would make more sense to actually prefetch a useful image from the domain concerned. Two birds in one stone! And I tried link rel="next" but it seemed to just grab the page again once they clicked. (I tried being really clever and adding a link based on the user's language using Javascript, on the theory that Russian users are more likely to click Russian, but while the link showed up in the DOM, it didn't seem to be recognized for the purpose of preloading.)

I feared this would send the front page over 2 TCP segments, but switching to HTML 5 and its !doctype html - hey, if it's good enough for Google, it's good enough for us - cut a significant chunk of hard-to-compress text out of the header, plus reducing other XHTML requirements like xml:lang, the head and html tags themselves, and closing option and li tags. It's actually a bit smaller tonight than it was last night. Browsers still treat it as standards-conforming - it just takes up less space. I'll have to try that on our wikis as well.

On an unrelated note, I wonder when phishers are going to realize that it's a bit of a giveaway to send mail in English using Cyrillic encoding . . .