If you’re expecting some kind of long winded tutorial about optmising, caching and super-charging your site, sorry to disappoint. The advice is:
Don’t use flickr
Ok, if you’re not a flickr user you’ve probably stopped reading already, but if not you might be rewarded by one or two nuggets of useful information.
The story starts with Hiro’s personal blog being at the top of hatena’s bookmarks page (think Japanese delicious). Unfortunately, it was hosted in-house about 2 metres away from where I am sitting. I think I can still smell the smoke :p
It was swamped, no-one could get through to it but we kept it up in some vain attempt to let whoever access the Evangelion related story. The server wasn’t tuned or optimised and only had a basic caching. But that’s beside the point, and as I said this post isn’t about optimising, caching and tuning.
After the above episode, Hiro moved his blog to Amazon’s EC2 cloud servers, just like our main blogs and also messa.tv
I was curious though, how much of an improvement was it? Obviously the EC2 server wasn’t on its hands and knees begging for mercy (or to be put out of its misery) but still, how fast was it to load?
The answer surprised me. It was slow, 32 seconds slow. Half a minute to load the front page!
I used BrowserMob’s free Instant Test to do the measuring, highly recommended and no the above link isn’t an affiliate link.
The reasons I recommend BrowserMob are because it tests from 4 different locations around the world, and the results are easy to read. Plus there is no set-up. I found it because I was searching for Load or Stress testing in a user friendly set-up.
Ok, I thought let’s try some of my own sites, set up on a Linode VPS. Tuned, cached and nginx based. And I was floored…
1.2mins to serve up the 347.2KB front page! I couldn’t believe it, I almost cried.
I looked more closely at the report and then discovered why it was taking 72 seconds to serve up 347KB. It was a flickr widget I was using, pulling down thumbnails of recent photos in my public pool. Whereas a full sized photo hosted locally on the server was taking 0.234 seconds to load, a thumbnail from flickr was taking 30.1 seconds. And because of the number of thumbnails I was loading, it did them in batches, so 6 thumbnails took 30 seconds then the next took another 30 seconds. Note that the files are tiny, 337 bytes not 337KB.
The advanced caching I set up didn’t help because the thumbnails weren’t local so were not cached.
So I disabled the widget and re-tested. New load time: 1.52 secs with no single item loaded taking more that 300 milliseconds.
Owwwww! (That was the sound of me kicking myself repeatedly)
I then went back to the report of Hiro’s EC2 hosted blog and found that it was the same, images from flickr were taking 30 seconds to load. He wasn’t loading as many as I was hence the total time of 32 seconds. BTW (EC2 vs Linode comparison tidbit) loading a local image took 2.2 seconds on the EC2 server vs my 0.234 seconds on my Linode server.
So here are the takeaways:
- Don’t use flickr for hosting images you will be displaying on your site
- Even if you’re confident you’ve got uber-hosting, check your site
- Your site may feel fast to you but it could be an illusion because of locality and browser (not server) caching
- BrowserMob makes it easy to do No. 2 and its free