After working on high-performance projects for a while (or aspiring to), it gets easy to build things in such a way that favors performance over readability. It’s good to be reminded every once and a while that while we develop code for computers to execute, ultimately it’ll be humans who will work with them.
Mobile web applications are an interesting example. A large portion of the code is downloaded and executed by remote clients, so we tend to pay more attention to total file-size, number of HTTP requests, and ultimately how much code gets executed on the other end. If we are graded on our work, surely this is what will be looked at. There are benchmarking tools such as Yahoo YSlow and Google Page Speed which help you analyze your site and suggest techniques to apply. Naturally, everyone wants an A or a high rating.
About a week ago, I was looking over one of my projects, and wondered what the hell happened to the code; it was awful. White-space was missing in a lot of areas, CSS was condensed (in most places), and even some of the PHP caching code was pretty hackish. Since I was having to rebuild a large component of the project for other reasons, I made an effort to clean up these concerning areas.
If you can optimize your architecture or design as you go, then by all means do it. What you shouldn’t do; however, is try and remove things that affect readability in favor of performance. I think there are two acceptable ways to do this… as part of a build/deployment script, or as a filter in production. Your development copy should always be for humans. Developer time is often significantly more expensive than server resources. Let’s look at some of the various resources we need to deal with…
If you’re using Zend Framework, check out these view helpers to use Minify with
Zend_View_Helper_HeadLink. Similarly, if you’re using Symfony2, check out the builtin component, assetic.
Whitespace / HTML File Size
Make your templates as readable as possible. There are two ideal choices to deal with this: gzip/deflate compression or a simple filter that removes extraneous white-space. Here’s an example of how you could set up compression. Add any of the following lines to your
Each particular line would enable deflate compression for the associated mime type. You can usually expect around 2/3 to 3/4 of your filesize to disappear when compressed. The other approach, which was a filter, would look like this:
$response = trim(preg_replace('/>\s+</', '><', $response));
This is blatantly taken from Twig‘s
spaceless filter. Note, there isn’t much point in using both of these techniques. It’s best to benchmark both (resulting file-size, server compression time, client decompression time) and decide for yourself.
Although not in scope of this post, you can do similar processing to images. There are command-line tools available to compress images, or remove meta data from them to help eliminate a few percent of file-size. This is definitely not the low hanging fruit, but interesting nonetheless. Don’t spend too much time optimizing specific images when it’s possible to run batch processing across all of your images at deploy or update time.
Do yourself and your peers a favor, write code with them in mind.