The interesting property of Lively that makes existing caching solutions not fit well is that Lively core concept is to allow changing data and code anytime. In order to still optimize loading we made very good experience with an approach that we call "combined modules". It basically means concatenating the core modules into one file and serving this file as combinedModules.js. In order to prevent the browser from caching scripts (normally the browser will automatically cache resources when it has already loaded the same URL) we also append a hash string to the URL (to make it unique). When you look at the first scripts that gets loaded at webwerkstatt.xhtml it looks like this URL: http://lively-kernel.org/repository/webwerkstatt/core/generated/combinedModules.js?fd1317b9543eefb0c2ae82deeaeaf2f8. Accordingly, the loading process when bootstrapping Lively looks like this: if (optimizedLoading) { var hashUrl = codeBase + 'generated/combinedModulesHash.txt', combinedModulesUrl = codeBase + 'generated/combinedModules.js', hash = JSLoader.getSync(hashUrl, true/*uncached*/); JSLoader.loadCombinedModules(combinedModulesUrl, thenDoFunc, hash); return; } Now the interesting question, how is combinedModules.js created? We are currently doing this for the webwerkstatt SVN repository in a post-commit hook that looks like this: #!/bin/sh combineModulesOnCommit.py --repository "$1" --rev $2 & We are passing the path to SVN repository and the newly commited revision to a script "combineModulesOnCommit.py". You can get it here: http://lively-kernel.org/other/combineModulesOnCommit.py What the script does is the following: 1. Figure out if the commit changed one of the core files? If not abort 2. Get and concatenate all core modules into one new combinedModules.js file 3. Generate a new hash for that file What is important when concatenating is the correct order of the modules. Since each module can depend on other modules it is important that dependend modules are inserted before. Since we can only determine this at runtime, Lively provides a method to output the topologically sorted module names: lively.lang.Namespace.bootstrapModulesString(); The result of that is placed inside combineModulesOnCommit.py and used when the concatenation takes place. (Note: That we only occasinally update this fixed set of core modules. This is OK since out module system is flexible enough to load in modules during the optimized bootstrap phase that aren't in this fixed set. However, those need to be fetched one-by-one from the server)