Friday, February 20th, 2009

Caching scripts in HTML5 Database

Category: HTML

Ian Collins has created DBScriptCache, a JavaScript program that “automatically caches script files in the browser’s HTML5 client-side database. Rather than including your scripts using script tags, you include them using this script. The first time a user views the page the scripts will be pulled into the db and stored. On subsequent visits the scripts will be loaded from the db cache and not from your server. The script will continue to come from the cache until you supply a new version number or change the name of the script.”

You can see it in action on Ian’s site:

  1. <script src="cache_loader.js">
  2. window.script_cache = window.script_cache || new ScriptCache();
  3. window.script_cache.includes([
  4.   ['js/brawndo.js','1.5'],
  5.   ['js/app.js','1.5']
  6. ]);
  7. </script>

Posted by Dion Almaer at 6:30 am
10 Comments

+++--
3.7 rating from 28 votes

10 Comments »

Comments feed TrackBack URI

Seems like a nice idea, but ill rather use expire headers..

instead of eval, why don’t you just create script tags, add the code as + text and append it to the head?

Comment by V1 — February 20, 2009

While it certainly is an interesting idea as a proof-of-concept, I fail to see the real-world scenarios, where this would be preferable to using cache expiration headers and versioning using url suffixes.

Comment by MorganRoderick — February 20, 2009

Well http headers only works on a per-url basis while say this would work by allowing say a library to cache itself globally. Although I’m not sure that’s even reasonable considering the security implications of allowing unknown third party users too cache something for you.

I suppose this would also be a workaround if you are on a badly configured server who’s backend you’ve got no control over. Although its so easy to switch hosting these days, so I doubt that’s a real issue.

Comment by KitSunde — February 20, 2009

I did something similar with googe gear for symfony (php framework). you can find it at http://www.symfony-project.org/plugins/sfGoogleGearCachePlugin

Comment by jeromeetienne — February 20, 2009

I did something quite similar, but with Support for JS, CSS (with images).

Uses modification dates and not version numbers to make things easier to deploy.

Works in Webkit only (but on the iPhone)

http://github.com/343max/dbfs/tree/master

Real-life example: http://i.edween.net (works only in Webkit Browsers)

Comment by 343max — February 20, 2009

Well the html spec say’s no one but the domain owner can change a html5 database as for security, I really like the idea anyway..

Comment by karnius — February 20, 2009

The reason for using this over expire headers is that iPhone currently wont cache any file over 25K (e.g. most JS libraries). Even if it were to cache large files, it has pretty aggressive cache clearing policies, including clearing the whole cache when it is hard reset.

The reason for using eval() over script tags is that I couldn’t figure out a way to sanitize the ” chars in the code properly in the amount of time I spent on this script. Without the sanitization, inserting the script’s code into script tags caused some nasty bugs. I still have a branch in my git repo that uses the script tags, though – if someone knows how to sanitize the code please message me on github.

I’m not sure why anyone would care about security issues in this case, but I guess that’s just all some people see..

Comment by 3n — February 20, 2009

343max – that’s pretty slick, well done. I didn’t have access to the mod dates since I’m doing it entirely in JS (no php 4 me), so I had to use version numbers :(

Comment by 3n — February 20, 2009

great tip. although i will never by using it, it is still a very good method.

Comment by sujith84 — February 20, 2009

this general technique can speed page loading by 30% or better esp for mobile devices. like 343max mentioned the If-Modified-Since/Last-Modified headers can be used in your xmlhttprequest (set/getResponseHeader) if/when you have them available instead of tinkering with versioning. that way you can delay or ignore 304/not-modified responses keeping persistent assets current in the background.

Comment by ujuxiun — February 24, 2009

Leave a comment

You must be logged in to post a comment.