Improvements for Madman’s Website

I noticed that Madman Entertainment recently made a few improvements to their website. These things were fairly minor – changing the log in confirmation button from "proceed to checkout" and allowing for cross-session log ins so you don't have to log in every time you visit the site – but go a long way towards improving the overall feel of the site. Since I've used the site for quite a while I thought I would go through some things that I think they should try to tackle in the near future.

I'll start off by stating that I am operating mainly from the output of YSlow and somewhat on my own observations and knowledge. I did this because I want to concentrate on things which should be a bit more obvious and more easily "fixable" than something which requires an in-depth understanding of obscure web development topics. Besides, I don't have access to their back-end system so I can only make general assumptions on anything except things sent to the browser. I believe the Madman site runs on a Java platform (because of a page of Java exceptions I got one day) so much of my PHP-based knowledge won't be applicable and I might have some misunderstandings about how things work. If so I apologise in advance.

Markup

It's great that they tried to use true XHTML, complete with XML declaration, but if you're going to go down this route then at least check that the [markup validates][1]!

The site also appears to use some non-standard attributes. I don't know why this is the case but seeing as they're not as dramatic as a supposed XML not passing a basic XML check I'm not going to worry too much about them. :)

Remove Commented Out Code

Really? Using HTML comments to remove markup from processing? May I suggest using Java comments instead? Or a version control system if you want to have access to previously written, but no longer needed, code?

Remove Excess Whitespace

This actually helps the first suggestion as well, seeing as the presence of whitespace before the XML declaration is one of the reasons the markup doesn't validate. If you look at the source you can clearly see gaping holes, which is filled with newlines and tabs.

For example, there is 81 bytes of whitespace between the text "Add to Basket" and the enclosing anchor tag. Every time. Is this really necessary?

As an experiment, I went through one of the HTML files and removed a bunch of the whitespace manually. Nothing drastic – just the big chunks of glaring space that I found. (I also removed the unnecessary commented out HTML and JavaScript I mentioned above.) I managed to eliminate 5K off the original 34K size. When gzip compressed (at -9), as would be done for HTTP transfer my "cleaned" version resulted in a filesize of 5.3K, compared to the original's size of 6.1K. A 13% saving on every page is certainly nothing to sneeze at for a site which has a large amount of traffic (I assume).

I understand the likely reason for this: when the code is seen in the template it is nicely formatted and so looks nice to the site developer. Who really cares about the code sent to the browser? It's not like people look at it anyway, right? (cough) Well, the two reasons to remove at least some of the whitespace are to allow the page to validate at the most basic level and to shave off some excess flab from page transfers.

Use Compression

The actual HTML is sent compressed, which is good, but none of the secondary files are. CSS and JavaScript are sent "raw", which isn't great when the basic CSS files are 21K all up and the JavaScript in the member area is a mind-blowing 152K spread across 8 files (they use Google Analytics as well but Google nicely sends that code compressed).

Compressing all the JavaScript files results in a total of 37.3K to download – less than the size of the prorotype.js file before it has been compressed! If all those files are combined before being compressed then an extra 3K is shaved off, leaving us with a 34.2K download, along with fewer HTTP requests to make to get it. This can be done with something like Ed Eliot's combine script, which is written in PHP but I'm sure the idea can be easily adapted to Java, if not the code itself.

Similarly, compressing the CSS files individually results in a total of 4.8K and combining them results in 4.4K sent to the browser.

Overall, this gives a saving of over 130K, just by using HTTP compression! Of course, this is only relevant for situations where the cache is empty but, at least according to Yahoo!, this is roughly half of the time. The Madman site doesn't use "far future" expires headers either so aggressive caching by the browser is not possible.

Minify JavaScript

This continues on from above. One thing you will notice in the newest version of the combine script is that it runs JavaScript files through JSMin before compressing them and sending them to the browser. What kind of savings would this give us?

I won't list the uncompressed results (see the table below) but the compressed size is 27.5K individually and 25.1K merged. Holy freakin' crap! This is roughly a 10K saving, even after gzip compression.

Of course, seeing as these files are served from the Madman server(s) there's no reason why a more advanced compressor can't be used. I chose Julien Lecomte's new YUI Compressor, which is currently at version 2.0, for this task. It should be noted that YUI-Compressor is slow and can't be used for on-the-fly compression like JSMin but this shouldn't be a problem as the compression can be done beforehand, whenever the JavaScript files are modified.

I'm sure you just want the numbers now, huh? When compressed: 25.8K individually and 23.1K combined. An improvement of 2K on top of JSMin and 128K over the original JavaScript files. Wow. And all with so little effort!

Here's a summary of the results for individual Javascript:

Comparisons between various JavaScript compression methods for the files on the Madman site.
File Original gzip JSMin JSMin+gzip YUI YUI+gzip
builder.js 3.3K 1.2K 1.9K 760b 1.5K 690b
controls.js 25.9K 6.9K 16.9K 4.4K 15.6K 4.2K
dragdrop.js 18.3K 4.7K 13.2K 3.5K 11.1K 3.4K
effects.js 29.5K 6.4K 22.4K 4.8K 20.9K 4.6K
fanzone.js 13.4K 3.6K 11.8K 3.2K 10.3K 3.0K
prototype.js 46.5K 10.4K 34.3K 8.4K 27.7K 7.7K
scriptaculous.js 2.2K 1.1K 793b 446b 710b 427b
slider.js 10.5K 3.1K 7.1K 1.9K 6.3K 1.8K

And here's a summary of the differences between using individual files and merged files:

Comparisons between using individual or merged JavaScript files.
Files Original gzip JSMin JSMin+gzip YUI YUI+gzip
Individual 149.6K 37.3K 108.4K 27.5K 94.0K 25.8K
Combined 149.6K 34.2K 108.4K 25.1K 94.0K 23.1K

As you might expect, merging files together does nothing when compression (rather than minification) is out of the picture. However, it is clear that running minifcation programs over the JavaScript files results in a very real saving on file size.

More YSlow Suggestions

  1. Make fewer HTTP requests. There are plenty of CSS background images which might be able to be combined into a CSS sprite. For JavaScript/CSS files a combining script like I linked to above would do the trick.
  2. Add an expires header. None of the external files have a far future expires header. Using these can be a bit dangerous if you don't set up the system properly to deal with changes to files (ie. the browser will get newer versions).

Minor Changes

I'd ditch the images in the footer, which are used in place of text. I doubt if many people read that far and, if they do, I doubt they're going to be bothered if the text isn't exactly as the designer wanted. While the images are minuscule, they still require 3 unnecessary HTTP requests. Personally I think the image-text is too blurry anyway. Similarly, I think the search image-text in the header can be replaced with actual text.

I think someone needs to check the log out button:

Logout button image is not on the same line in logout link in header

This could just be an issue with Firefox on Linux but, even so, it's really annoying.

Conclusion

I did focus more on performance issues than I would have liked but, then again, the responsiveness of a site directly affects the usability. For example, who wants to wait around for 150K of JavaScript files to download when, with a few small changes, they could be downloading 23K?

Most of these things should be pretty easy to fix/improve and I've tried to provide suggestions for how to do so. I have other suggestions for improvements but they're significantly larger and more ambitious undertakings. :)

Overall, I think incremental improvements to a site are definitely the way to go. Madman have been using this kind of approach in their site updates and have started embracing RIA-like functionality, such as in-place editing, helped by cutting edge libraries like Prototype/Script.aculo.us. I hope these trends continue into the future.

[1]: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.madman.com.au