With that in mind, it *is* possible to construct a webserver config to serve up gzip content to browsers that support it.

Here’s my config for nginx. It should not be hard to produce an equivalent for apache.

http://tumblelog.jauderho.com/post/27655495

Do you look through your HTML source and find similar dependencies between them? And how do you find a good balance between code that can be combined into a single file and the ability to use reuse files for cached files between different pages?

Of course, I wouldn’t advocate developing a medium to large project with only one JavaScript or CSS file. That can get seriously unwieldy when it comes to code management, team programming, and source control. But at the end, when you push your code to production, you should trend towards that goal.

I haven’t really been comfortable Gzipping content until IE6 gets the last stake in its coffin. Do you guys sniff clients to feed Gzipped content?

I’ve been thinking that it might be a good idea to pick up Steve Souder’s book on performance optimizations for the web. A lot of that stuff is just so much more complicated that just writing good code. And that’s definitely something I need more information on.

For example, on http://buzz.yahoo.com your browser will see one JS and one CSS for every page. However, in development, we often had 2-3 JS files for each major component, and nothing is minified. Our build script parsed through each page when it was installed on the server, and shrunk everything down into nice browser-friendly packages.

If you don’t have a build script (which is fine in many cases) then you’re left balancing the needs of browsers with the needs of the development team, and the two groups often differ in what works best for them.

Personally, I can’t stand CSS rulesets all on one line. My eyes and brain just can’t parse it.

Only around 10% of the browser’s time is actually spent waiting for/parsing the HTML content. The vast majority of the time is spent waiting for external components, applying CSS, and running JS. With gzipping, the overhead of whitespace is minimal, so the isn’t much advantage to removing whitespace from markup. Some bandwidth “saving” techniques actually *increase* the size of the gzipped content, so it’s important to actually measure output rather than just counting the characters removed.