@Kari great question!!!!

To some degree won't websites always be about knowing your demographic and pushing the limits to what you can get away with? The YouTube, or MTV.com for that matter, of today would never have survived in 1999 and the 1999 version of MTV.com would survive today but be less than acceptable and be easily trumped by a competitor -- the interest of its audience would be lost quickly.

I think there needs to be clear and candid separation between designs like the Web Designer Wall and CSSBeauty for example. One is more of a design while the other is more of an art. I don't mean to criticize or diminish quality by implying that cssbeauty isn't "art". But art being more self expression and free artistic in nature than a beautifully designed site like cssbeauty. Web Designer Wall is whatever the author says it is -- it can take 100 years to load or less than a second -- it can have navigation on the top, bottom of running sideways -- it doesn't matter as long as the creator likes it. While more traditional sites need worry about load time, image size and knowing that "content is king".

I think it depends on what your site is, who your audience is and what your sites objective is. I think web designer wall is for web designers -- who are most likely on faster machines with amazingly quick internet speeds. While the BBC for example can't make such assumptions and a 170k background image is probably a poor choice.

I worry about it -- I also try and aspire to having the base template be no more than 100k with all images and complimentary files; that is sometimes easier said than done.

I guess I like to take the Google approach when it comes to designing a user experience. On the other hand, it seems that worrying too much about things of that sort are causing some headaches as well.

edit: Furthermore, nowadays I spend a lot of time researching subjects like, for instance, eyetracking. Take a look here, if you will.

Recently I've been experimenting with a couple of designs for a site that will contain so little information that once you've read it, you can recite it in your sleep. So the question is: do you serve that information as fast as possible, or do you enhance it with something aesthetically pleasing to create a positive association with the site and the service. I opted for the latter.

For those of you who think that a pretty package doesn't absolve you from having nothing inside I'll add that it did occur to me, too, and that I did eventually solve the problem with a clever web service. Having minimal amounts of textual content feels acceptable when it's 100% relevant and useful.

edit: Do you think that at least some of the efforts spend on optimizing the layout, compressing your headers and what not are somewhat wasted when you have to load oodles of background graphics, or do you even concern yourself about the minutiae of optimizing code?

total page load should not exceed 30KB, then later 50KB, now it's not unusual to be almost 100KB.

I managed to keep my latest project at 40KB and it still looks reasonably good. I use a couple of caches for RSS feeds and news pulled from a database to keep the load times in check. Almost everything is compressed before being sent to the browser, not counting images, of course. YSlow for Firebug helped a lot, even though it has been criticized. The rating I got was 80, but I'm pretty sure I can get it closer to 90.

There are some tradeoffs to consider with all this optimization, so does anyone know a decent way of benchmarking websites or PHP code? WebKit and Firebug are both all well and good, but I'd like to hear about some alternatives, if you have any.

I agree with what everyone is saying in the above, it really depends on what you can get away with. We're still in a web world where people enjoy the full flash site with an insane amount of graphics and 30 second load times, and we also sit there swearing at our computer if google doesn't load within a fraction of a second. It's a bit hard, but I would say it's largely based on your demographic and website purpose. I know it's extremely hard to keep a site under 100kb now given that many AJAX frameworks will push that over quite a bit, not to mention if you want to be incorporating some nice use of graphics to employ that look that is unobtainable being 100% CSS driven.

kari, I would love to see the design you did that was under 40kb and hear more about what you decided to give up or put in!

This question should be answered early on in the design phase. You should understand your target before you lay a single pixel on a blank PS canvas. It just so happens that designs intended to reach the widest audience, the ones needing most optimization, typically need the least amount of flair.

So, the question is not ours to opine. It's you, the designer's, to answer. Really, it's your audience's to answer.

I'm thinking that this should be done without having to figure out whether or not the audience would prefer a site that loads a bit faster. This should be done because it's easy and it makes sense.

That's one of those steps you should always take. Yes, you're right. I'm thinking more about design decisions: Complex textured backgrounds, tricky AJAX interaction and JavaScript animation, etc. Each decision requires a small cost/benefit analysis with respect to the site's audience.

Let's take a look at rule #4 - Gzip components. You can compress your HTML by adding this line at the beginning or your index.php file

<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>

and that's about it. The CSS part is also quite easy. Make a new PHP file in the same directory with your CSS files. Let's call it gzip-css.php.

<?php

// gzip-css.php

ob_start ("ob_gzhandler");

header("Content-type: text/css; charset: UTF-8");

header("Cache-Control: must-revalidate");

$offset = 60 * 60 ;

$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";

header($ExpStr);

?>

Then add this to your .htaccess file:

AddHandler application/x-httpd-php .css

php_value auto_prepend_file gzip-css.php

These two lines look for requests for CSS-files and put them through gzip-css.php, which will compress them. You should notice quite a drop in transfer sizes. Use either WebKit or Firebug with YSlow to compare the results.

P.S. I'd credit these lines of code to someone else, if I could remember who they were.