The article addresses a few issues you may have with packaging assets into "rollup" files:
1. If you set your JS or CSS rollup file's versioning number as the (root) revision number for your entire codebase, then editing an unrelated file will bump your rollup file version and unnecessarily void the previously cached version. Clients end up re-downloading the exact same file.
2. Google App Engine and other proxy caches may exhibit problems with the query string versioning technique: all.js?v={version}
The solution is to derive the version number of the rollup file from the version numbers or a hash of the contents of the actual files included, and to include this version number in the rollup file name, not the query string: all-{version}.js instead of all.js?v={version}
There are a number of other considerations that the author didn't cover. I will mention the ones related to what is included in an asset rollup file:
1. If you need to include a popular third-party library such as jQuery or YUI, utilizing Google or Yahoo's CDNs may likely result in a resource cache hit even for visitors brand new to your site. [1]
2. If you have certain JS or CSS files that you update frequently, they would be candidates for splitting off into a separate rollup file. Thus, frequent visitors will only need to re-download the contents of the smaller, frequently updated rollup file.
3. Different sections or pages of your site may warrant different rollups. If a high k-weight set of JS/CSS files are required only for admins or for an infrequent task such as uploading files, you may not want to have every visitor of your front page downloading all that k-weight.
These decisions require looking at the cost of extra HTTP requests and added complexity versus the amount of downloaded KB saved. But they are worthwhile considerations for optimization.
Great tips. I've always wondered what the cache hit ratios are like for various site's userbases when using Google or Yahoo's CDN for a popular library.
Smart. There's a Django app, jezdez's django-compressor, that will do this for you, including packaging and minifying JS and CSS then generating a file with the new hash in its name in the way this article describes.
Does it support hosting/syncing the static content to a 3rd party service like s3?
The problem with most of these asset management apps is i can't use the templatetags, since they save new css files etc. During deployment i usually ship the static media to S3.
I haven't tried to do that myself, but django-compressor has a management command if you don't want to use template tags, which are really just there for the convenience factor:
> The concatenation and compressing process can also be jump started outside of the request/response cycle by using the Django management command manage.py compress.
I prefer to load resources like Jquery using googles CDN and then pack my own javascript separately. Using something like HeadJS you can load both items non-blocking and in parallel.
1. If you set your JS or CSS rollup file's versioning number as the (root) revision number for your entire codebase, then editing an unrelated file will bump your rollup file version and unnecessarily void the previously cached version. Clients end up re-downloading the exact same file.
2. Google App Engine and other proxy caches may exhibit problems with the query string versioning technique: all.js?v={version}
The solution is to derive the version number of the rollup file from the version numbers or a hash of the contents of the actual files included, and to include this version number in the rollup file name, not the query string: all-{version}.js instead of all.js?v={version}
There are a number of other considerations that the author didn't cover. I will mention the ones related to what is included in an asset rollup file:
1. If you need to include a popular third-party library such as jQuery or YUI, utilizing Google or Yahoo's CDNs may likely result in a resource cache hit even for visitors brand new to your site. [1]
2. If you have certain JS or CSS files that you update frequently, they would be candidates for splitting off into a separate rollup file. Thus, frequent visitors will only need to re-download the contents of the smaller, frequently updated rollup file.
3. Different sections or pages of your site may warrant different rollups. If a high k-weight set of JS/CSS files are required only for admins or for an infrequent task such as uploading files, you may not want to have every visitor of your front page downloading all that k-weight.
These decisions require looking at the cost of extra HTTP requests and added complexity versus the amount of downloaded KB saved. But they are worthwhile considerations for optimization.
[1] As previously mentioned by iamjustlooking.