There are many tools and applications to help you squeeze the most from files prior to deployment or automatically at runtime.

Cool, but where?
And how do I set up GZIP on my server?

]]>By: NetNerd85http://www.sitepoint.com/9-causes-of-web-page-obesity/#comment-70153
Thu, 22 Apr 2010 13:20:49 +0000http://www.sitepoint.com/blogs/?p=20027#comment-70153I agree that you should watch 1 and 7 but the rest are not really things to worry about apart from the obvious techniques to reduce size. I don’t think you should go crazy and freak out that your CSS is not optimized for size. I’d rather it be readable for myself and others that want to view it.
]]>By: Niubihttp://www.sitepoint.com/9-causes-of-web-page-obesity/#comment-70152
Thu, 22 Apr 2010 10:52:59 +0000http://www.sitepoint.com/blogs/?p=20027#comment-70152So how do websites like http://www.dubli.com fit into this scheme? I’m new to this kind of thing and I’m finding it hard to get a handle on it to be honest. Practice makes perfect, I guess :)
]]>By: tiggsyhttp://www.sitepoint.com/9-causes-of-web-page-obesity/#comment-70151
Thu, 22 Apr 2010 09:22:05 +0000http://www.sitepoint.com/blogs/?p=20027#comment-70151It’s possible to resize images using php. My biggest sites use a lot of images, but at small sizes. I wrote a script that works every night to pick up images in gif, png or jpg format and produce the optimized versions used, which has speeded up my site so much it’s incredible.
]]>By: Craig Bucklerhttp://www.sitepoint.com/9-causes-of-web-page-obesity/#comment-70150
Thu, 22 Apr 2010 09:21:46 +0000http://www.sitepoint.com/blogs/?p=20027#comment-70150Thanks richthegeek — some good points.

Sprites do affect size and speed. Every request receives the file and header information from the server. Therefore two 100 byte files still require a larger overall data transmission than a single 200 byte file.

I agree that the savings you can make in CSS are far smaller than those with images, Flash, etc. But look after the bytes and the kilobytes will look after themselves!

There are really only three things to worry about: Flash, images, and code.

Flash is by far the worst for weight and processor clogging (makes some pages unusable in Linux), and cutting them out is generally worth the time investment in pure usability and conversion rates.

Images tend to be more vital, and time yields smaller, yet still significant gains. That said, there is a big difference between resizing an image (huge saving) and compressing to the optimal quality (mediocre saving) in most cases.

The point about sprites is not so much about size (although there will be gains here) but connections. The browser will only open so many synchronous connections to the same server at the same time, so if you have 30 images to load and each one takes 0.5s to connect, you will be looking at upwards of 4s in just domain resolution. The two solutions are to either use multiple sub-domains such as img1.amazon.com and img2.amazon.com, OR to remove the issue entirely by compressing them into a single sprite. It’s not *size*, it’s *speed*.

Finally, code – the sizes here are frankly piffling when you look at time/savings. Even with a fully verbose CSS being 4 times the size of the compressed/top-level rule, the saving would be maybe 100kb with Sitepoint’s quite weighty CSS. Considering that can be more than saved with even one image being resized, it’s a huge time investment (although it’d be easy to write some code to automatically minimise a sheet).