I’ve been a regular Flickr user since the beginning of 2006 and remain a loyal Flickr Pro member despite increasing usage of Facebook’s photos amongst my friends. Putting aside feature & design differences one noticeable difference between the two is in sheer speed of browsing. I decided to compare Flickr, SmugMug and Facebook Photos as they illustrate 3 different approaches to photo browsing, with quite dramatic speed differences.

Flickr takes a whole page approach to photos in that browsing from one photo in a Photostream, Set or Pool loads a whole new HTML page and its associated contents.

SmugMug takes an AJAX approach. Clicking a photo in the current album does not load a new HTML page but triggers two important HTTP requests:

The first is obviously the image requested by the user, the second is any associated comments. Flickr in its whole page load approach can avoid the separate comment load request since it can directly embed comments into the page HTML, however that is still slower than the SmugMug AJAX approach because the page HTML has to be loaded before the browser knows what image to fetch. SmugMug’s AJAX approach enables it to avoid the HTML page load, and also to fetch the image and comments in parallel HTTP requests resulting in a snappier user experience.

Facebook also takes an AJAX approach but goes one step further by preloading images. Upon viewing the first image in an album a simple ((new Image()).src=... is used to preload the next image. Simultaneously, an asynchronous request is made for the album’s metadata which is returned as a JavaScript blob. The metadata describes all images on the current page (of 20) which allows Facebook’s javascript TaskQueue to begin preloading further ahead (at time of writing it preloads up to 4 images ahead of that currently being viewed).

The metadata also contains all comments & tags for every photo on the current page of the album. The current page size is 20 so Facebook has potentially saved 19 HTTP requests by retrieving all comments & tags in one request if the user browses through every photo. The tradeoff is freshness – if a new comment or tag is added during the current browsing session they will not show up, though this would not seem to be a major issue given that in my experience the comment rate is very low on most photos.

The end result is that when advancing from one image to the next the user waits for a single HTTP request for the image in the worst case, and in most cases does not have to wait at all since the images are typically preloaded.

In my testing Flickr’s HTML page alone takes roughly 1.5 seconds to load (450ms waiting for the server to respond, and upwards of 1000ms to load 17kB of HTML). The exact times aren’t as important here as the fact that, ceteris paribus, advancing from one image to the next on Flickr is at the very least 1.5 seconds slower than SmugMug or Facebook.

The pre-loading approach makes sense in some instances. If the user is looking at an image within an album of photos from a birthday party they recently attended they’re quite likely to browse through at least a few other images in the same album. The tradeoff is that inevitably there will be some waste in preloaded bytes. If you’ve clicked into an album because one of your friends was photographed at a conference you probably won’t be clicking through the other 500 photos of random strangers at the conference.

We hope to continue highlighting real world examples of front-end techniques for improving web application performance. If you know of other interesting examples please let us know by leaving a comment below.