SmugMug: Showing off AJAX’s Chunk in the Trunk
January 22nd, 2007 by Robert Yeager
I was surprised to read this TechCrunch story about an upgrade to SmugMug’s interface this morning, since I have SmugMug’s CEO Don MacAskill’s blog in one of my Protopage RSS readers and would have expected to read about it there first. I’ve been watching SmugMug due to my interest in Amazon’s S3 and EC2 web services.
SmugMug’s user interface for browsing photos is now done w/ AJAX. You can read about the changes and benefits (according to them) here. I decided to give it a test drive for myself here.
I was initially very impressed with the improvements. As I’ve stated before, AJAX makes a nice incremental improvement for legacy HTML web applications. I would go so far as to say SmugMug is a prime candidate for AJAX, since it is really not a web application needing RIA technology, but rather a traditional static hyperlinked website.
After playing around with the new interface for a few minutes, I started noticing that something wasn’t quite right…the performance was much slower than I would have anticipated for something as simple as navigating around photos. I really noticed this when I switched to a different browser…there was a noticeable lag when SmugMug’s photo navigator loaded.
I decided to take a peek under the covers using a sniffer program called HTTPWatch for IE. After clearing the browser’s cache again and reloading the photo navigation page, here is what I captured (click to enlarge):
What I have highlighted in blue is all the Yahoo’s YUI AJAX libraries and SmugMug’s own code that drives the presentation of the photo navigator. The approximate size of all these libraries is about 330KB. Add in the graphic elements and HTML itself is about another 50KB. So, without the photos that you want to view, SmugMug’s photo navigator is almost 400KB of code and graphic elements. Jeez!
For comparison, Cooqy’s eBay search engine weighed in at around 280KB the last time I measured. The amount of functionality within Cooqy is equivalent to a full-blown desktop application…Cooqy is immensely more functional than just a few fancy hovering semi-transparent navigation tools. My point is that SmugMug’s 400KB runtime is way out of whack for the delivered functionality.
I found it amusing to read about the tribulations the SmugMug team had in making the AJAX technology work across different browsers. I am always pleased to never have to worry about cross-browser compatibility issues when developing with OpenLaszlo.
I was a bit puzzled to read about their efforts made to preserve the browser forward/back button behaviors, as if the AJAX toolkits caused problems. Cooqy makes use of the browser buttons to navigate search results from the OpenLaszlo-generated Flash UI. Took me all of 5 minutes to get this operational, again with cross-browser support.
Not to take anything away from the website improvements SmugMug have accomplished, but is the penalty of a 400KB runtime and what appears to have been a long and intensive development effort really worth a couple of fancy floating semi-transparent navigation widgets?
I believe that just the photo navigation tool within SmugMug would have had much better results written as a small OpenLaszlo application. I believe the download size for such an OpenLaszlo-powered navigation tool would be less than 100KB. I also estimate that this tool could have been built in a few hours by one person, with the end result supporting all browsers.
If you would like to see an OpenLaszlo photo browser application for Flickr photos, take a look at the LZPix demo here.
6 Responses to “SmugMug: Showing off AJAX’s Chunk in the Trunk”
Leave a Reply
You must be logged in to post a comment.
The entire YUI library can be minified + gzipped to 30 KB, according to this post:
http://yuiblog.com/blog/2006/10/16/pageweight-yui0114/
You’re likely seeing uncompressed page weights in your reports.
And on a side rant, LZpix shares some UI elements with Yahoo! Photos, though it’s a compliment. :)
I’m comparing apples to apples, since the OpenLaszlo-generated SWFs can also be gzipped…I’m measuring the byte size of the delivered libraries in the browser with the HTTPWatch tool, not their compressed sizes over the wire.
In my side-by-side tests with a cleared browser cache, the LZPix Flash demo starts up as fast or faster than the SmugBug’s photo navigator…but the LZPix’s demo has a lot more functionality and doesn’t suffer the pains of cross-browser compatibility that the SmugMug team has documented in their development.
>99% of our viewers gzip the data, so 400KB is a fairly unfair estimate. It’s pretty rare these days for anyone to not have things served compressed.
Lets not forget that the vast majority of modern browsers “perfectly cache” the JavaScript, too, so if they’re viewing more than one page, as the majority of our viewers do, they only pay the hit once.
I don’t believe OpenLaszlo properly solves the browser history problem in Safari. I could be wrong, and I’d love to see their solution, but I believe that’s true. IE and Firefox, sure, but they’re the easy ones.
Having said that, this is a brand-new release and there are some obvious areas we can improve that didn’t manifest themselves until millions of people were using the software. As always, we’ll release updates frequently until we like the end result. :)
Don
Hi Don,
GZIP helps over the wire, certainly. Like I mentioned, the OpenLaszlo-generated SWFs will be gzipped as well. I am still surprised at the size of the AJAX runtime in relation to the provided functionality.
The OpenLaszlo-generated SWFs also get cached by the browser, too. No advantage to Javascript in that regard. Maybe your servers are being hammered today, but even in this test the LZPix demo app starts up faster for me than the SmugMug navigator from cache. Since each is loading from cache, this may indicate that Flash initializes faster than the AJAX library.
I don’t have Safari, so I can’t speak to the OpenLaszlo integration with its buttons. I do see an open defect report in OpenLaszlo’s defect tracking tool, however, scheduled for a fix in the next v3.4 release.
So it seems that instead of a few hours to provide full cross-browser compatibility like I stated in my write-up, I would have to allocate time to fix this issue in OpenLaszlo. Like many AJAX toolkits, OpenLaszlo is open-source, so anyone can make repairs as needed. Since your blog mentions the struggles in this area, it sounds likely that you solved the problem across all the major browsers…maybe your team has the solution in-hand that can be plugged into OpenLaszlo.
Still, I doubt the development costs involved with the new SmugMug AJAX UI would compare favorably to the costs of a comparable OpenLaszlo interface. In the end, money tends to make a fine measure of good vs. not-so-good business decisions.
I’m not trying to second-guess you or to discredit your accomplishment…what I am trying to do is to educate readers of my blog to the issues of RIA technology selection. SmugMug made for a dandy case study of AJAX.
Thanks for taking time to stop by and provide your feedback. Best wishes for your continued success.
Kind regards,
Robert
I’m wondering if they used any of the new javascript libraries, like jQuery, prototype, scriptaculous, etc that automatically take care of all the cross-browser compatibility issues. I couldn’t tell from viewing their source. In case u are not familiar with these go to:
http://prototypejs.org/
http://script.aculo.us/
http://jquery.com/
There are many reviews out there that compare them. For the moment I really like jQuery because the code is short and powerful.
I totally agree - Ajax is highly overrated! Rich internet applications have their place, and providing better user interaction and seamless refresh is fantastic when used carefully; but it also makes cross-browser development difficult and very expensive if you go overboard.
The example that comes to mind is the Yahoo “new mail beta” or whatever it was called. I’ve been an enthusiastic user of Y!Mail for over ten years, and switched to the Ajaxified version as soon as it came out - it’s main feature seemed to be that it looked like Outlook and it ran dead-slow! Luckily I was able to switch back …