If you’re writing a web application from scratch, there are a lot of things you need to account for. Security, performance, usability, accessibility, cross-browser support, the list goes on and on. In the decade and a half that I’ve been doing web work, the focus has shifted from writing web sites from scratch using a HTML editor to using a CMS (Content Management System) such as Drupal or WordPress. CMS’s do the heavy lifting for you… they have security built in, are tested for performance and usability, have accessibility plugins, and most have well behaved cross browser support.
Honestly that’s why my own website here is using WordPress. Why re-invent the wheel? Well, sometimes you need a big gnarley wheel that doesn’t exist yet. That was the case with Maestro, a huge compliance documentation system I wrote for NMSU Research. Since I wrote it from scratch, it needed all those things I wrote earlier, and I had to write them myself.
I may talk more about other aspects in other posts, but today I’m going to talk about performance. Performance isn’t as much of an issue as it used to be. 15 years ago, filling a web page with huge images, gifs, or even, heaven forbid, music, could slow things to a crawl pretty quickly. The intervening years have seen a steady increase in internet bandwidth, so downloading huge images isn’t much of a concern anymore. Still, there’s no reason to be blase about performance. Might as well shave off bits and bytes where you can as a general good practice.
In the world of huge scale enterprise applications, however, simply avoiding a devil may care attitude isn’t enough. When you’re talking about hundreds of thousands of lines of code, to include recursive functions and many database calls, performance can become a real issue. Many tools exist to help diagnose bloated code, and any programmer worth their salt knows how to use a benchmarking kit. There are a few places, though, that small gains, which add up over time, can be had simply by knowing the right tricks.
Some of this is mitigated by caching… the act of saving the file locally on a client’s machine so that it doesn’t need to be re-downloaded every time. Caching is great, but it requires the programmer to properly set the timing of the file, or set a blanket timeout on the server.
Another issue which seems insignificant on it’s face, is that there’s usually a lot of wasted space in these files. Every space, carriage return, or other extraneous character represents a bit that must be transmitted. Even if the file is cached, the transmission of these superfluous characters must happen at least once.
My compressor class takes all the CSS files you feed it, combines them all together, finds all the images from those files and places them in a single location (so the path references will match up correctly) and runs YUI Compressor on the resulting file. At the end, I run a quick hash of the file names along with the last modified time of each file. I use the resulting hash as the file name of the combined file. That way, when my user comes back to the app, I can use the file name to quickly determine if any of the css files included have changed, or if any need to be added or removed. If everything is the same, I just stick the file name in a CSS tag. If not, I re-run the compression and then stick the new file name in a CSS tag.
See the Code
To see what I’m talking about or to get a copy of the code, check it out on GitHub.