Check out the Yslow score for the Websqueeze homepage: grade F (fail), 42%.

Before you think I'm being holier-than-thou: I'm not much better. I get a D, 68%.

Here are a few things that stand out:

• 12 (!) javascript files; several of these at least could be combined to reduce HTTP requests.
• 4 stylesheets; at least 3 of these could be combined (same reason).
• No far-future expires headers (for stuff like the above, and images).
• Nothing is Gzipped. This is just a waste.
• Almost nothing is minified.

So that's why the big Squeeze gets a big, fat F. Apart from the damning Yslow score, however, there's a more worrying number: the homepage is 500+ kb! Almost all of this (456 kb) comes from images and javascript.

8 of the 25 images account for 90% of the total 271 kb image file size; these large images look to me as though they have not been optimised (I feel their file size should be smaller, given the image content).

The 3 Jquery javascript files account for 85% of the total 188 kb javascript file size. This is especially shabby, because jquery.js and jquery-lastest.js are (almost) the same file (the former is a minified version of the latter; it's also a more recent revision by three days). So you've included the Jquery library twice.

Note that Jquery compresses down to about 16 kb, when minified and Gzipped.

Sorry to whinge, but web-expert sites like the Websqueeze ought to be examples of good practice in this respect. At the moment, it's an example of how not to make a fast website.

I'm going through the Yslow tasks myself at the moment, so if I can help, just ask...

Thanks Mike for letting me know about all this. I do agree that speed is a very important factor, and I will try my best to alter the code generated by our CMS to speed up the site. Right now I am recompiling Apache with mod_deflate. That should speed things up even more, and I'll work on it till we get a passing grade.

Mike, also let me ask you something.

Where are you finding out the total filesize of the site? Is that in firebug, or another plugin?

I have installed mod_default and configured it to compress all data. However, I can't compress the content which we are getting from other servers. (e.g. BuySellAds, Jquery...etc.) I would blame most of these problems on IPB and Wordpress. It's going to be very difficult to alter their core, and I'm not even sure if it's possible as some of the files are encrypted.

That's helped already. Down to 423 kb.

As for a "passing grade" -- I wouldn't worry too much about your particular grade or score. It's more about improving the speed/score as much as you reasonably can.



Firefox web developer add-on --> Information --> View document size



Well, you can only alter what you can alter. But why are you getting content from the Jquery site? I use Jquery too, but I put the library files on my site (a "local" copy). You appear to have both "local" and remote copies of the same library.

Here's an example of compressing your images. The WebSqueeze text logo (logo.jpg) is 46 kb. I edited it as follows:

• Opened it in Photoshop
• Saved it as an 8-bit PNG
• Ran PNGcrush on it

The result is a 20 kb file that is visually indistinguishable from the original 46 kb image (I believe it's pixel-for-pixel identical). Here you go:



This took me about one minute. Most of the savings came from choosing the right file type; PNGcrush only shaved off a tiny amount.

I shaved a few kb's off of my two images but can't do anymore without losing clarity.

Just thought I'd say "well done" for the improvements. TWS home page is now 354 kb (removing 30% of the file size). It also gets a Yslow score of 57, which is a 15-point improvement and only 3 points off a D grade.

You could still knock 25 kb off that "The Websqueeze" logo (removing 56% of the file size), however, without losing any image quality.

I'm risking myself here but I would say pointless. WS has never been slow. I don't care what score it gets, it's the people that are using it. Few kb's here and there don't make a difference. Not even few tens of kb's. When I was at school (almost 10 years ago), they tought us to optimize better and then we did count kb's but those days are over. Also combining files can lead to messier maintenance more often that actual noticable speed increase.

Ok, now you can start ranting me: 1, 2, 3, GO!

You might think it's pointless, but that's probably from ignorance of some key background ideas.

First: response time is important. Even on broadband, most sites take a few seconds to load each page. Let's say your website typically takes 5 seconds to load a page; that might seem good, but what if it took 1 second, or even less than 1 second? Think how that might affect a user.

Yahoo has found that reducing response time creates an increase in sales. Users like fast websites, and the faster the better.

That is not to say that all websites should be bland pages of text. Modern websites often need to be rich in media and interaction. So although removing all images would speed up your website, your users probably would dislike that. But if you can speed up your website without sacrificing your content or design, and without imposing an unreasonable maintenance burden, then why not do it?

Second: response time is extremely highly correlated with page weight; the correlation coefficient is something like 0.96. Third: response time is highly correlated with inverse Yslow score; the correlation coefficient is something like 0.76. So reducing your page weight and increasing your Yslow score are almost guaranteed to create real performance benefits.

It's really about educating yourself. Many of these things are not difficult; they do not require much work. The real investment is in the time spent learning about them.

Let's take the Websqueeze logo as an example. In a matter of seconds, I was able to reduce the file size from about 45 kb to about 20kb. That's a saving of 25 kb, or about 7% of the total page weight. 7% might not sound like much, but if you were able to do the same thing 10 times over, you'd reduce the page weight by 70%; and consequently, the page would load about 3 times faster than before (say, 2 seconds instead of 6 seconds).

It took me seconds because I knew what to do. I could see that the image used relatively few colours, and this immediately made me think of converting it to a PNG-8. I also have PNGcrush set up, and it just takes a click to activate it.

That's funny.. you're afraid Mike is going to prove you wrong, and he does it.. Loving it

But I'm still not going to buy it Technically you're all correct but I still don't think it matters. If your website loads for 6+ seconds, there's probably a lot more wrong than just image optimization or separate javascript files (to a point ofcourse). By makin that 6+ second site load in 2+ seconds of course matters but let's take websqueeze as an example. WS loads for me in 1-2 seconds. It really doesn't make me any difference if you can make it .5 seconds faster. Maybe it's just me.

It doesn't make any difference for you, maybe. But for other people, it does.

Not everyone is on broadband, and not all broadband is equally fast. Moreover, TWS loads fast for you because you're viewing it with a primed cache; what about visitors with an empty cache? Do we not care about them too?

I recently made some measurements of TWS load speed as part of my Yslow article. On my broadband connection, it takes 4 seconds before any text loads (on an empty cache), and 10 seconds before the homepage has finished downloading. And on simulated dial-up, of course, it took much longer.

I'm not saying that TWS is especially slow, but it's not especially fast either. I mention these ideas because TWS is the product of several expert web designers, whom I know are all interested in learning how to improve the quality of their creations. I know they are professionals, and I expect them to care about continuous professional development. They have already taken several of my suggestions on board, and as a result the site is now faster.

You say TWS loads in 1 -- 2 seconds, and that you wouldn't care if it loaded 0.5 seconds faster. Well, a 0.5 second improvement would be 25 -- 50% of the load time. How do you think Yahoo would feel about that?

If I could discover a secret method of cutting Yahoo's response time by 25 -- 50%, then Yahoo would pay me a fortune for it. Yahoo care; you don't. You are free to disagree with them, of course; but I'll take their assessment over yours any day.

Having said all that, there is always a balance to be struck. You can spend forever optimising your website, trying to squeeze that last 1% out of performance; it's important not to become so obsessed with performance that you never get around to making any content. But many of these practices, such as basic image optimisation, take almost zero effort. This is why Yahoo chose to focus on the front-end with Yslow: back-end performance tweaks are much harder, and only account for 5% of response time. Frankly, you might as well not bother tweaking the back-end. Yet this is exactly where many hand-coders strive for perfection, by creating minimalist markup; they work hard on the 5% back-end, while ignoring the 95% front-end.

It's up to you. You can choose to learn something that will make your websites better, or you can just shrug your shoulders and say, "I don't care." I chose the former.

I agree with you that some basic optimization is always in place, but I emphasize the word basic. I'm not going to spend hours squeezing 5kb off that logo filesize. I asked a friend to open WS and asked if it was slow. It wasn't and for sure he didn't have it cached. If the users don't see any problems, why should we?

And so that we don't agree on too many things I disagree with the frontend-backend ratio too Well depends where you look at it but where it matters the most (commercial web applications) it's usually the backend that makes the seconds go by. Of course a basic website with nothing fancy in it is another story but I would still think the backend is more than 5%.

Hours squeezing 5 kb? As I keep saying, it took me mere seconds to remove 25 kb. I consider that basic.



The back-end only becomes an issue if your web server is completely overloaded. This happened to me recently, because I was paying $2 a month for hosting; at that price, I'm not surprised they crowded too many sites onto the server.

Other than this edge case, you really don't have a leg to stand on. Take a look at Steve Souders Google Tech Talk presentation. This guy is telling Google how to optimise their web properties.

http://www.youtube.com/watch?v=BTHvs3V8DBA

In this video, Steve explains how his career had previously been as a backend engineer. When he began Yahoo's Exceptional Performance studies, he first decided to test where the response time is spent. Once he discovered that the backend was only 5%, the whole direction of the project changed to frontend optimisation.

Can you provide a better argument than Steve Souders does?

**edit**

Actually, it might be that the backend is 10 -- 20%. I remember that number from somewhere too. Check the video for the numbers.

In Steve's definition, the "frontend" is everything that happens after the browser receives the .html file (or .php, or whatever). Okay, here are the numbers:

• For Yahoo.com, 95% of response time is spent on the frontend for an empty cache.
• Overall, including primed and empty cache page views, 80 -- 90% of the time is spent on the frontend. This holds for almost any website.
• Response time is 94% correlated with page weight (note: above 50% is considered a strong correlation).
• Response time is 76% correlated with inverse Yslow score.