Page Speed results for Blueprint – GWT FTW

February 6th, 2010 Alex Moffat Posted in GWT, Web | 2 Comments »

Earlier this week Page Speed 1.6 Beta was released. This is a Firefox/Firebug Add-On that evaluates the web pages using a series of best practices that are known to improve page load time. You get a numeric score, maximum 100, and specific guidance about the best practices the page does, or does not, follow. It’s very simple to install and use so of course I went out and measured the performance of some pages, including Blueprint, to see what Page Speed thinks we’re doing right and how we compare to others.

First of all, some major sites from around the web, starting with www.google.com, which scores 95/100. That’s actually the best score of the sites I looked at. Next we have arstechnica.com and my.yahoo.com with scores of 86/100 and 85/100, and finally, news.bbc.co.uk and www.nytimes.com which both score 71/100. You can go and check these results for yourself using Page Speed.

For Blueprint I measured the home page, the process page, the project page, and the admin page. The home page scored 93/100 and the other three all scored 92/100. I think that’s a better than respectable performance. There’s always stuff we’d like to improve but good results are, I’d like to think, a result of paying attention to performance and using GWT. Paying attention makes sure we devote time to performance and GWT gives us the tools to make things better.

In fact Page Speed pointed out the same issues for all the pages.

First, a small number of files, which should have long cache expiry times, such as images, didn’t the them set. These were all images that were either not in ImageBundles, which is the predecessor to ImageResource provide by Client Bundle in GWT 2.0 or, in the case of images used from CSS, were not inlined in the CSS using data urls. I wrote a post earlier last year describing how as part of our build process the CSS is combined and compressed and images are inlined where possible. The CSS file is given a strong name using the same technique as the GWT generated JavaScript files so it can be cached forever, just like the GWT generated JavaScript can. Using GWT has made it much easier for us to aggressively cache resources.

The second issue is that we have more than one JavaScript file loaded by each page. However, that’s not too bad as we only have two, one for the GWT generated JavaScript and one to provide page load timing information by hooking into the the GWT lightweight timing system. It would be possible to put the timing code directly into the HTML to save a request. This is in contrast to many sites that end up downloading tens of JavaScript files. I’ve seen pages constructed using dojo that download more than fifty. We also get nicely compressed JavaScript out of GWT.

Finally we have some inefficient CSS. This isn’t something I’ve looked at before. Page Speed points out CSS selectors that are know to be more expensive for at least the Mozilla rendering engine to evaluate. Something to modify for our existing CSS and add to our CSS coding standards.