I wanted a simple solution to bundle and fingerprint the assets of my homepage, which is built with Jekyll.
Existing solutions seemed an overkill. It turned out that I could achieve the same result with a simple script.
Cache Busting. Another good practice is implementing a cache busting strategy, that is, a mechanism that invalidates the cache of browsers when our assets change.
This, however, can be a problem when the cached assets are actually changed: if the browser already has a local copy, it might not check for new versions and our website might not render as intended.
There are various techniques to avoid this issue. A simple approach consists in revving (or fingerprinting) assets, that is, changing their filename when their content changes. Common techniques use timestamps, version numbers, and the SHA of the file. If you are interested on the topic, see Cache Bust that Asset for a review of cache busting techniques and HTTP Caching for an excellent introduction about caching.
If you are on Jekyll, the situation is a bit more complex. There are, in fact, various plugins, such as Jekyll Assets, Jekyll Minibundle, and Jekyll::Littlefinger, providing different degrees of automation. However, their integration requires a bit of work and, in some cases, there are some quirks: for instance I could not integrate Jekyll::Littlefinger and Jekyll’s support for Sass.
Fortunately, the operations required to bundle assets can be easily performed from the command line and, thus, I decided to write a bash script to bundle and fingerprint the assets of my website.
Here it is:
One important bit of the script is the generation of the
file, which keeps the correspondence between original and
fingerprinted filenames. When fingerprinting, in fact, assets names
change everytime an asset is modified; referencing assets from layouts
requires to be able to compute the correct name (or update them
manually everytime they change).
Jekyll data file and, more specifically, the
assets.yml we generate in the
script come to the rescue, since we can use it in our layouts to load the
proper asset, as follows:
The important bit is the
site.data.assets['main.css'].digested which gets
the name of the fingerprinted
main.css asset. See Example: Accessing a
specific author for more details.
Now, every time I change my assets, I run the script above to generate fresh copies of my assets.
The solution might be simple and naive (there is no deletion of all assets, to name one), but it works, it is blazing fast, it helps limiting the number of external dependencies, and the complexity of the build process. If you have spent time debugging a toolchain which stops working after updating some components, you probably know what I mean.
Asset bundling and revving can improve the performances of your website/webapp and there are many nice tools which support us very well in complex workflows.
There are situations, however, where a simpler and more robust solution is there at hand: we just need to think about what our requirements really are and what we really need from the tools we use.
Get in touch