On Sunday 21 October 2007 9:54 am, John ORourke wrote: > Here's a different take on Apache2::Filter::Minifier. I run a small web > dev shop, I code perl and manage the servers, and I have a small team of > web developers who make works of art using JS and CSS. I have a few > hundred man-hours* per month for development. We're talking about > simply deploying a module to speed up some sites, without it using up > many man-hours. Thanks, Community!** This helps me proudly tell my > customers about mod_perl, and in will help my business get to the point > where we can contribute code and ideas back to the community.
Appreciate the comment. The minifiers initially stemmed from my wanting to be able to minify JS/CSS on sites that we host/maintain for our customers, where I'm not even necessarily party to doing the actual build/deployment. With these minifying filters, their JS/CSS code gets minified on-the-fly and then cached to disk using mod_cache in accordance with whatever expiry headers they've set up for themselves. Although some of these guys have designers that'd be willing to do the minification themselves before uploading the files its a whole lot easier for me to tell them that it'll just happen automatically, the same way that mod_gzip or mod_deflate auto-compresses the content before it goes across the wire. I agree that minifying on each and every request is a total waste of cycles. Unless the original file has changed, re-minifying it is just duplication of effort. This is why the docs include notes on how to set up mod_cache to cache the output. I'd originally considered building in my own caching code, but settled on mod_cache in the end as it meant that (a) I didn't have to build any of it, and (b) it'd let me focus the minifying filters on doing one thing and one thing only (minifying the JS/CSS). -- Graham TerMarsch
