Secs sell! How frickin' fast this site is! (client side)

30 March 2012   7 comments   Web development

Mind That Age!

This blog post is 5 years old! Most likely, its content is outdated. Especially if it's technical.

Powered by Fusion×

Secs sell: How frickin' fast this site is!
After a lot of optimization work on this website I finally now get a score of 98 on YSlow! Phew! Finally!

I've managed to get near perfect scores in the past but never on something as "big" and mixed and "multimedia" as this, ie. the home page. The home page on this site contains a lot of content. Lots of thumbnails and lots of code.

As always, it really helps if you can control the requirements. Meaning you can say "No, we don't want an embedded Flash widget with 30kb Javascript". In my case I didn't want content to be dynamic per each user request so the underlying HTML can be properly cached. Also, I don't need any Javascript for the home page because all it does is static content.

Secs sell: How frickin' fast this site is!
My individual blog pages are the only pages that require Javascript. What I did there was let Google host a copy of the latest jQuery and I just add some minified code to handle the AJAX of the comment posting. It's pretty cool that the individual blog post pages get a score of 99 on YSlow even though they contain a decent amount of Javascript.

What I've also done is moved every single image, css and javascript element to the Amazon CloudFront CDN. Yes, this costs money but certainly not much. My web server is located in London, England which is a good location but considering that 70% of my visitors are based in north America it's more fair that 90% of the web page content is served near them instead. This is clearly illustrated with this screenshot from Pingdom.
Secs sell: How frickin' fast this site is!

I'm quite aware that it's 100 times easier to build a fast website when you can simply disregard certain features such as fat picture galleries and massive blocks of Javascript stuff. But mind you, choosing not to add those features is a large part of making fast websites too. The number one rule of making a request fast is to not make it at all.

I'll soon blog more about how I made these things happen from a technical point of view.


thanks !!
It is indeed crazy fast! I had a look at your source on github and it looks really clean and proper.
If you can – don't use jQuery. There several advantages to it.

First of all people wouldn't need to download that much garbage, which won't be used anyway (you use only some jQuery functions, right?). Prefer using libraries suited for your specific needs – these in most cases are lighter (about 80%) and faster...

Secondly, all that garbage wouldn't be executed – that too drains several microseconds of CPU time.

Thirdly, hand optimized plain JavaScript itself executes faster.
Peter Bengtsson
Will it make a big difference? Obviously a lighter version of jQuery is fewer bytes to download. But then again, there's no Google CDN to use maybe and because the Google CDN URL for jQuery is the same across different sites people who visit my site might already have it in cache.

The question is, does loading big standard jQuery result in excessive amounts of Javascript executions? That might really matter on a mobile device. Perhaps more so than saving 10Kb.
I skimmed trough your JavaScript code and basically all you do is AJAX requests. Everything else could be written with same amount pure-JS (and some polyfills for older IEs).
Now jQuery is ~32kB gzipped. For AJAX you could use for example which is only 3kB when gzipped.

As for library evaluation speed I mixed up some test cases (
Bear in mind, that even tough jQuery can be cached, it needs to be reexecuted from scratch for EVERY load. So you can think that every load is counting 2*2 for 1 million times. Waste of processing power, isn't it?

On side note it is pretty hard to write Javascript that IE is willing to execute.
So because on an average computer it can only do it 250 times per second it's an issue...

This is typically one of those cases of optimization where it's not necessary. Saving 4ms on a request isn't going to change the users experience. In fact, if you have a high concurrent amount of users, transmitting that small library from your own servers would probably cause more delay than 50 page loads combined, and it might even influence the concurrency. (Of course, this is just as minor and neglectable as the 4ms it takes to load jQuery.)

Think about the whole picture, before talking about optimizing. In fact, there are sites that load slow, because they're built to serve 10K requests per second to all people, if they'd optimize the experience for each individual person, the page might load half a second faster, but only 2K requests could be handled per second.
Thank you for posting a comment

Your email will never ever be published

Related posts

IssueTrackerProduct now officially abandoned 30 March 2012
Secs sell! How frickin' fast this site is! (server side) 05 April 2012
Related by Keyword:
All your images are belong to data uris 06 January 2013
Introducing: HUGEpic - a web app for showing massive pictures 03 November 2012
Is Nginx obsolete now that we have Amazon CloudFront? 28 July 2012
DoneCal homepage now able to do 10,000 requests/second 13 February 2011
RequireJS versus HeadJS 09 January 2011
Related by Text:
Secs sell! How I cache my entire pages (server-side) 10 May 2012
Nice testimonial about django-static 21 February 2011
DoneCal gets a grade A (92) 27 November 2010
Secs sell! How frickin' fast this site is! (server side) 05 April 2012
Lazy loading below the fold 26 October 2013