You could do better than that and read the documentation on headjs.com. I just double-checked and I do see it mentioned that you need to set long expire head

You could do better than that and read the documentation on headjs.com. I just double-checked and I do see it mentioned that you need to set long expire headers and cache your scripts as much as possible. As a side-note and tip: ----------------------- The way we're doing that right now is by generating unique URLs for JS assets if they change and setting long expiration times, so the files are cached in the browser for as long as possible. If the resource changes, so does the URL. This is done only once at build time. This URL includes the first 8 characters of the sha1 hash of this file: http://example.com/js/004aa641/index.js Using URL rewriting rules at your server end you can strip the hash out and use this: http://example.com/js/index.js We initially tried setting the hash as a query string parameter, but many proxy servers don't cache static resources the URLs of which have query strings appended to them. Therefore, we moved to including the hash into the URL itself and rewriting it at the server end. What it looked like with the hash for a query string parameter: http://example.com/js/index.js?004aa641 If you deploy your Website in this manner, it lets head.js do its job, gives you maximum resource freshness, keeps resources cached for the longest duration, and because the hash changes for only those resources that have changed, only those resources are downloaded again. Keep your scripts sizes smaller than 25k for mobile phone browsers to be able to cache them permanently. This should hopefully cut down the amount of bandwidth consumed for your Website by a very large margin and improve the "speed" of rendering of your Website than by only using labjs or headjs. Cheers, Yesudeep.