In case anyone noticed, we’ve done a bit of client-side optimization. Namely:
- Javascript and CSS files are now ‘minified’ (I prefer ’squished’) as part of our build process, using the handy YUI compressor - this shaves a good 40% of bloat off our Javascript and 20% off our CSS, and makes them ever so slightly quicker to parse at the other end too
- Common Javascript and CSS includes are now packaged up into combined packages, which saves a lot of HTTP requests
- Javascript includes have moved to the bottom of the page, meaning they won’t delay page rendering
Some stuff we were already doing:
- Far-ahead Expires headers on all static resources, meaning they’ll be filled from the browser’s cache without any HTTP request where possible
- Gzipping static files with lighttpd - this shaves a good 76% off our Javascript for example (and still 74% off the minified javascript). It also shaves 82% off CSS, and interestingly manages to shave even more (83%) off minified CSS - indicating that stripping syntactically-irrelevant information actually makes the remaining data more amenable to compression in this case.
Some more still to do
- Convert PNG24s to PNG8s with alpha. Yes PNG8s with more-than-just-1-bit alpha do exist! and are considerably less bulky than PNG24s. Sadly neither Photoshop nor imageMagick can export them, but Fireworks, or the PNGNQ utility can. They don’t work too well in IE6, but then what does…)
- Consider using CSS sprites and background-position hackery for some of our icons, where possible, to cut down on requests
- Serve up static files from assets1.playlouder.com and assets2.playlouder.com, to increase the number of concurrent requests browsers make (they typically limit to 2 per hostname)
- Optimize our javascript to improve page initialization times - browser-native getElementsByClassName may help here, as may selectively delaying some DOM lookups until they’re needed, and using more bubbled-up event handling to avoid the need for more specific DOM lookups
- Optimize the crap out of the server-side (another topic for another day…)
This monday I shall be giving a talk at the London Ruby Users Group. I’ll be giving a tour through our experiences building a modular composable Widget UI framework ontop of Ruby on Rails. Some of the steps we took along the way, problems we encountered, and a tour of the results.
There’s also a juicy debate to be had comparing the REST-driven web application architecture pushed by the Rails project, with our more modular widget-based approach, and in deciding what’s appropriate for your application. For those in the know, comparisons abound with the approach taken by Avi Bryant’s Seaside framework, and the Apotomo plugin already in development for Rails.
The framework comes with a client-side component too, and means of serializing Widgets to constructors for corresponding client-side javascript classes - so the talk may also interest those attempting to do Javascript in an unobtrusive, object-oriented way with Rails.
After that I believe (sincerely hope 
) there are drinks.
The talk is open to all but the venue ask that you Register here; see LRUG for more details.
Turns out, unbeknown to me, someone had already invented a buzzword for my “optional ajax navigation” technique.
“Hijax” - because it Hijacks clicks on anchor tags and form submissions, and takes them over with Ajax.
I wonder if his code deals with all the same tricky corner cases that mine does, though.
Turns out someone’s made a dynamic history library for jQuery too. It looks a lot more modern and less verbose than the dhtmlHistory code we’re using at the moment - any kindly souls fancy porting it to work with prototype.js ?
As a web developer who’s been through a lot of pain in the last 5 years trying to support this backwards browser, I have to say this was rather a relief. We’ve previously attempted to get everything functional, if not feature-complete in IE6, but after the latest round of changes we just didn’t feel it was worth the considerable additional effort. IE6 users will now see a politely-worded message:
You appear to be using Internet Explorer 6. While Playlouder might work OK for you, it’s not supported by us, and there will probably be a few problems. For a better browsing experience, why not upgrade to Internet Explorer 7, or get Firefox. Either of these will ensure a great improvement in your experience of the Playlouder site, and should improve your general internet experience and computer security too!
We didn’t take the decision lightly - but we feel it’s the way forward. Google analytics tell us that around 60% of Playlouder users (loudplayers?) are accessing the site from Windows, and of those 60% using IE6. So that’s a sizable 36% chunk of our audience we’re asking to upgrade. Why?
- IE6 is, to put it politely, extremely backwards and its lack of standards support is unrivaled by any other widely-deployed browser
- With IE6 users now in the minority, the web needs compelling sites to start requiring an upgrade for IE6 users, to really spur upgrades and push that figure down even further
- We’re already requiring invites for new sign-ups, and feel that the upgrade isn’t too much of an extra step for users who’ve already had the motivation to seek an invite
- We’re not forcing any ideology on users - while I’d personally prefer they use Firefox, I’d be equally happy if they carry on using what appears to be their preferred browser (IE), provided they upgrade to the latest version. IE7 is easily available and people need to be told that the older version just won’t cut it on the web any more.
- The additional development costs just aren’t worth it for us at this stage - especially bearing in mind that given another year or so IE6 should be consigned to the dustbin of browser history.
Apple has a new public beta of Safari 3! Nice to see all that work on the Webkit engine reach a wider audience.
The reason I’m excited, though, is that the new Safari has some great web development tools built in which previously were limited to the (somewhat unstable) nightly WebKit builds. There’s a great DOM inspector, you can view the engine’s render tree, and most crucially, there’s support for a decent javascript debugger. Previously debugging javascript in Safari has been hell.
How to get this working:
- Install the public beta, and reboot (sigh - stop making me reboot Apple!)
- Download the latest nightly build of webkit, and install Drosera from the dmg
- Enter the following into your terminal of choice:
defaults write com.apple.Safari WebKitScriptDebuggerEnabled -bool true
defaults write com.apple.Safari IncludeDebugMenu 1
- Fire up the new Safari, fire up Drosera and attach to Safari. Note the Debug menu and the Drosera goodness.
Note the new Safari supports custom CSS for form elements, although seems to switch to using some slightly dubious non-apple-looking custom widgets the moment you touch the CSS.