We recently discovered that from countries with typically low broadband bandwidths, only about half of our first time visitors sticked around while Yast was loading. This was a serious problem and we decided to find out what we can do to better this ratio.
The total size of a first time visit to yast was 1.3MB, which is huge! We knew this, but we’ve always followed a few simple rules regarding program optimization:
The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet. – Michael A. Jackson
Those rules have saved us a lot of time and the performance has always been more than satisfactory. Another famous quote says:
Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you have proven that’s where the bottleneck is. – Rob Pike
In our case, we know the problem and we know the bottleneck. The size of Yast needed to be reduced, and this is how we did it:
- Removed old and obsolete code: We shaved the JS code base by ~15%
- Advanced JS minification using Googles closure compiler (which reduced compiled size by another 15%). http://code.google.com/closure/
- Gzip compression for all files and AJAX requests (~65% compression rate), using apache’s mod_deflate: http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
- Browser caching: A new caching system which allows long term caching of static files without creating upgrade-problems.
The total size of first-time-load went down from 1.3MB to 285kB, that’s a 78% reduction! (456% faster load time). The total size of a refresh is now only 30-40 kB, which is mostly volatile user data.
We are now working with optimizing the image graphics using CSS sprites. Yast makes >50 image file request which creates a lot of overhead. By using CSS sprites this can be reduced to ~5 requests. The file size will be the same, but the load time will be a lot better. This optimization will be uploaded with the next yast update. We’re using the open source tool SmartSprites to automate the process: http://csssprites.org/
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%
I think we used about 4 hours doing these optimizations, which is a lot less than 3% of our development time With a reward of a 456% speedup, we should have done this a loong time ago.