Thoughts on using HTML5 app manifest to speed up stuff

There is a well-known joke regarding the use of regular expressions:

Some people, when confronted with a problem, think
“I know, I'll use regular expressions.” Now they have two problems.

I'm starting to think my time playing with app manifests in webpages might've been better spent coming up a new version of that joke.

A good example of when to use it? A single-page web-app where any and all externally loaded files still live on your server. Case in-point: my Little Alarm webpage I made a couple year ago to remind myself to take breaks and shift gears every so often. You can view the cache manifest here but it's only three files: the main index.html file (all of the JavaScript involved is inline), the icon that appears as a favicon and in the desktop notification that appears when the timer is done (way too big and way too ugly) and the mp3 files that gets played when a set amount of time has elapsed (a weird sound byte I made with the very fun and kinda pricey iPhone app Animoog).

That little software snack uses a PHP file as the cache manifest with a simple script that looks for the most recent timestamp among files in that directory and prints it as as version # at the bottom of the file. The reasons for this are better explained by reading the documentation on how the HTML5 cache manifest works but it turned out to work really well — I have a completely functional, offline web-app that can automatically update itself when I change the , the icon or the sound byte.

So I thought to myself: Is there some way I can leverage this on my blog? It would be a bit redundant with the way browsers generally cache CSS and JavaScript files — plus I don't get enough repeat visitors to benefit from how the manifest would work — but if it was simple enough to implement I thought it would be an interesting experiment.

That leads to our bad example: If you're running a WordPress plug don't just add a willy-nilly cache manifest file to your theme. Between the CDN and other externally loaded content it was a complete mess. I'm not sure if all browsers do this but Chrome seemed to really choke on files loaded from other URLs.

But here's an interesting use-case: you can use the app cache(Have you noticed I can't seem to stick to a single way of referring to this? ) to pre-load others pages on your site while simultaneously dictating that other items — CSS, JavaScript, etc. — should always be loaded "live" over the network. It's a little bit like pjax but actually less involved, in theory.

How can you use this on your blog? Well, this idea came to me late and I've implemented very roughly, but the pages across the main navigation for this site are all preloaded via the manifest file when you arrive.  That means jumping over to about, contact or projects should load basically all of the content from cache even if it's the first time you're visiting the page.

The trade-off here is that the first time someone visits your page they'll be met with a slightly longer load time as those pages are pre-fetched... However it's only prefetching the HTML for those pages so it's not a noticeable difference. What is noticeable is the relative zippiness it gives your site as you move from page to page.

The next step would be to expand the cache file to automatically preload all of the blog posts you see in the "Recent Posts" sidebar.

Hmm. I'll come back to this whole idea with less tired eyes and try to do some actual, measured tests. In my initial testing it looks like this idea... might be working in Chrome.