We all know how beneficial to the performance of a web application it can be to serve assets like CSS files and JavaScript files in larger chunks as opposed to smaller ones.
The main reason behind this is the latency incurring from requesting a resource from the server plus the additional bandwidth of the request metadata which can grow quite large when you take cookies into account.
But knowing this, we also want to keep files separate during development to help us with the debugging and development process. We also want the deployment to not increase too much in difficulty, so we naturally dislike solutions that require additional scripts to run at deployment time.
And we certainly don’t want to mess with the client-side caching that HTTP provides.
And maybe we’re using Smarty and PHP.
So this is where sacy, the Smarty Asset Compiler plugin comes in.
The only thing (besides a one-time configuration of the plugin) you have to do during development is to wrap all your <link>-Tags with {asset_compile}….{/asset_compile} and the plugin will do everything else for you, where everything includes:
- automatic detection of actually linked files
- automatic detection of changed files
- automatic minimizing of linked files
- compilation of all linked files into one big file
- linking that big file for your clients to consume. Because the file is still served by your webserver, there’s no need for complicated handling of client-side caching methods (ETag, If-Modified-Since and friends): Your webserver does all that for you.
- Because the cached file gets a new URL every time any of the corresponding source files change, you can be sure that requesting clients will retrieve the correct, up-to-date version of your assets.
- sacy handles concurrency, without even blocking while one process is writing the compiled file (and of course without corrputing said file).
sacy is released under the MIT license and ready to be used (though it currently only handles CSS files and ignores the media-attribute – stuff I’m going to change over the next few days).
Interested? Visit the project’s page on GitHub or even better, fork it and help improving it!
gnegg 