So the browser has to make 64 different server calls and pull down 349 Kb just to start doing anything. This can clearly be improved on.
Turning on server-side gzip, is a good way to reduce the amount of data transmitted with no real downsides. Also putting everything in one file will help a lot, but more can still be done.
Now because everything is better in table form:
Name Files Size (Kb) w/ GZip (Kb)
Original 64 349 100
Concatenated 1 349 54
YUI 1 139 28.2
Packer 1 80.7 28.3
This shows near 85% improvement just by putting everything in one file and turning on gzip! But even better, the filesize can be halved on top of this.
My first instinct was to go with the Packer encoded version: it's the smallest (or close enough) whether the user's browser supports gzip or not. But the YUI compressed version is my recommendation. Why? Well I'm glad you asked! The vast majority of visitors' browsers will accept gzipped files, so for them there's no filesize difference between YUI and Packer. Now with YUI you can just un-gzip and you're away, however with Packer you unzip then decode then you're good to go. This additional step will still halt rendering until it's complete, making the page load feel slower - the exact thing we were trying to improve.
There you go, a good library made better! Now onto hacking it.....