wiredfool

One of the things with webapps now is that they load a ton of extra stuff, javascript, css, images, static pages. Lots of extra stuff. The work site has something like 15 includes of one variety or another on each page, and a bunch more that are loaded as needed on one or two pages. That’s a lot of latency.

One way to fix it is caching and expires headers, another is to minify and compress the javascript and css, and another way is to just get the files near the user so that they can load all the items without round trips to the server. Big sites do this with a CDN, a content distribution network. But two drawbacks of that approach are that they’re not from the same site for origin purposes, and you generally have to pay for a CDN, and that’s out of the reach of smaller sites. On the other hand, they do it without you noticing, and gears does require confirmation and trust.

Google Gears has a local server and cache space that are intended for use in taking applications offline for later syncing with the cloud. But it’s just as useful for serving bits in conjunction with the online version. The important thing is that everytime there’s a request for one of the files in the cache, gears will serve it locally. That’s a lot less latency.

Best of all, it’s pretty easy to setup. You include the gears_init.js file, create a local server and assign it a manifest. The manifest controls everything that gears will download once and cache, until the version number in the manifest changes.

The javascript changes, cribbed from wordpress’s version of this and the google docs.

<script type='text/javascript' src='gears_init.js'></script>".
<script type='text/javascript'>
       if ( 'undefined' != typeof google && google.gears ) {
             var localServer = google.gears.factory.create('beta.localserver');
              var store = localServer.createManagedStore('cdn-store');
              store.manifestUrl = 'gears-manifest.txt';
              store.checkForUpdate();
       }
</script>

And the manifest file:

// site-manifest.txt
{
  "betaManifestVersion": 1,
  "version": "1",
  "entries": [
    { "url": "gears_init.js" }
	{ "url": "common/prototype.js" },	
	{ "url": "common/scriptaculous.js?load=effects" },	
	{ "url": "common/effects.js" },	
	{ "url": "and so on and so on...." }
  ]
}

I’m not sure that this is a total game changer for the general web, but for sites that are apps where the users both trust the site and spend a significant amount of time there, it’s a win. This is already being used for the admin interface of WordPress 2.6. I can see it being used in a lot of places with rich interfaces where the users are highly invested in the site and latency is a concern.