AutoVersioning of Static Content
Versioning of JavaScript, Images and CSS files while improving page performance and eliminating the manual process of changing versions after the code is deployed.
Why do we need versioning in static content?
When a user visits a website for the first time, all the static content i.e images, css and javascript files used by the page gets downloaded. When the user goes to another page, if the javascript file used by this page is identical to one of the already visited pages, it will not be downloaded again from the server. It is served directly from the browser’s cache. In case, the content is not present in browser cache, then the request will go to CDN. In case the CDN is not able to serve the request, the request will now go to the origin servers. So, the main objective to improve web performance is to make fewer http requests to servers.
For static content, caching is achieved by setting up an expires header for each static file, e.g. Expires:Thu, 31 Dec 2037 23:55:55 GMT
The header above means that, as long as the file is in cache, the browser will not make any request to the server for that specific file. Like, for the header mentioned above, it will not make any requests to the server until the year 2037.
This all looks good, but as our website grows, new features are added. Thus new files are added, removed and modified. So every time we send a production release, we need to ensure that users get the latest version of static files.
And that’s why it is required to add a tag/version to the static files which will act like a cache buster.
Versioning: The earlier approach
Earlier, we used to maintain the versions of static content in a yaml file on our application servers. There was one version number per type of static content, which looked like below:
The number signified the version of current javascript or css assets. So, whenever there was a new deployment of static content, we had to manually change the version of the assets in order to get the latest ones. There were not per file versions as that was even more tedious.
This approach had major drawbacks:
- Even though there was a change in only one javascript file, we need to update the version of the entire static asset folder. The downside was that all those files which were not even changed had to be re-downloaded at the CDN and the client’s browser making unnecessary requests to the same files thus lowering the page performance.
- It required manual effort to change the versions of static assets every time there was a release and clearing the cache of the applications!
New Approach
A solution to this is to implement a per-file strategy but in an automated fashion. With tools like Grunt, webpack which are capable of not only to version our static assets (using hashes, date etc.) but also able to produce a version mapping which is consumed by our back-end application controllers.
The version mapping or the assets-manifest.json file contains key/value entries of the assets and their uri.
This means that whenever an asset changes, the uri corresponding to that asset will change and the rest of the assets will remain the same.
By using the above strategy we were able to overcome the drawbacks which we had earlier.
So, now comes the next step which is to send this asset-manifest json file to our backend application controllers. There could be multiple approaches to achieve this, like,
- The very first approach that comes to the mind is to download the asset-manifest.json at runtime and load the static assets. But this decreases the page performance as we are wasting some milliseconds to download the manifest file at runtime.
- The second approach is to pre-download this asset-manifest file from our static servers. So, when the request comes to the application controller, the manifest file is already present, therefore the static assets would load faster in this scenario!
To achieve the 2nd approach, we made a few configuration changes in Webistrano, the deployment tool. The change was to trigger an automatic download of the asset-manifest file onto application servers whenever the static code was deployed through webistrano.
Thus, the complete process of deploying static content is automated which has made deployments hassle free. Also, the performance is improved by serving files from cache until they are actually modified.
Hit the 👏 (claps) button to make it reachable to more audience.
