July 11, 2012

Template Speed Optimizations

On Monday I was able to add some significant improvements to our frontend CSS and JS aggregator script that allows us most of the same flexibility we had before, but adds both server and client side caching improvements.

by Nick Shobe

The Results

On Monday I was able to add some significant improvements to our frontend CSS and JS aggregator script that allows us most of the same flexibility we had before, but adds both server and client side caching improvements. So far our average page load(full DOM load) time has dropped from a range of 2.3-2.5 seconds to one of 1.4-1.6. It’s always exciting when a simple improvement yields immediate results, but to shave off an entire second on an already fast website is difficult to achieve.

Combined with our earlier spring Apache changes we have shaved off two seconds from our fall average page-load time. For the most part we owe most of this to our new-relic performance monitoring for showing us where we needed to improve as well as providing almost immediate feedback that our changes where working the way we intended.

The Fix

The main change was to send 304 not modified when the various CSS and JS files haven’t changed. This tells the browser that it may use the cached version of it’s file rather then download the 30-40Kb of needed code on every page load. For comparison, a normal CSS file is about 30Kb(compressed) while the headers are only 298bytes. At first it was just caching and not sending the response, but now it even caches the aggregated files for five minutes because it seemed to save an additional 10th of a second on the server.