Introduction

In todays environment of Rich Internet Applications we rely heavily on Javascript. Often this javascript is in the form of a javascript framework. These typically enhance vanilla javascript and allow you to accomplish tasks with a nice syntax and more importantly abstract the differences in browser implementation.

Despite all the positives the main negative of javascript frameworks is the browser overhead when they are downloaded. Often the size of these assets can add up to a few hundred kilobytes. Coupled with the fact that they are normally split into a number of files (increases HTTP Overhead) this has the effect of decreasing the quality of the user experience while they wait for these files to load when loading your site.

There are a number of ways to increase client side performance specifically with javascript assets.

Decrease HTTP Overhead

Combining assets into single files is the best bet here. Prototype and Scriptaculous take up five or so separate uncompressed files. Decreasing HTTP overhead is one of the biggest time savers.

Caching

This involves telling browsers that they can cache a file for a time in the future. This is known as the expires header. Mod_expires is a way to achieve this with Apache. It is common to append a timestamp to the url eg.

/javascripts/defaults.js?343423434342

A technique which is applied by rails is that this number value is infact the last modified timestamp from the file so you can then set a long expires on this (maximum possible) as changing the default.js file will alter the file, change the timestamp and generate a new unique URL which can be recached.

Gzip Compression

Another big timesaver for big assets. This actually zips up the asset before pumping it down the pipe. You can configure this in your nginx configuration or use mod_deflate if you are on apache.

Javascript Compression and Optimisation

This area still developing, the main players at the moment at the YUI Compressor developed by Yahoo and the Closure Compiler developed by Google.

I use a basic prototype / scriptaculous framework for oentries so have used this for a little battle between the compressors.

Compilation commands are as follows for reference.

YUI

  java -jar /path/to/yuicompressor-2.4.2.jar --type js -o defaults.yui.js defaults.js

Closure (Standard mode)

  java -jar /path/to/compiler.jar  --js defaults.js --js_output_file defaults.google.js

Closure (Advanced Optimizations Mode)

  java -jar /path/to/compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --js defaults.js --js_output_file defaults.google-advanced.js

NOTE: You need to be running Java 6 to use the closure compiler.

This experiment was performed on a 1Gb Ubuntu Hardy Heron VPS Slice.

Comparison of Compression (Kb)

YUI and Google Closure standard mode produce a similar result circa 60% of the original size. However closure with advanced optimisations leads the way at 43% of the original size!

There is however a BUT. The advanced optimisations mode actually removed methods which are not called! Have a look at these docs

In a standard RIA you will often call functions from inline HTML (onclick events) etc. This makes this form of aggressive optimisation too much for standard applications. You could however remove all javascript calls from HTML and so it all unobtrusively as it standard practice in JQuery.

Comparison of Compression Time (Seconds)

YUI is substantially faster than google closure at JS compression. If you were to add this into your deployment strategy this gives YUI the advantage.

Compressor Conclusion

Whilst it looks like closure is a better compressor, I just don’t think it is safe to be this aggressive with compression for production environments.

If you then run closure on standard mode, the differences in compression vs YUI are minimal. With the speed advantage of YUI, I would definitely pick YUI. YUI has the other big advantage in that it can compress CSS as well.

Has anyone had any experience with Javascript Compressors? Comment if you do.

Conclusion

I hope this has given an insight into the wonderful world of speeding up the delivery of your javascript assets. Now get out there and compress!

I really like when the baby grinds the rail on his roller skates. Its interesting to see how far the branding of water has come!

flickr

I am proud to announce the official launch of Simply Excited as a business. Initially offering a range of services from fresh project development to consulting, systems administration and training.

The aim for simply excited is to provide elegant solutions to the complex problems of the internet.

Simply Excited has already completed number of different projects which have been released to the wide world.

If you have an idea for a project or would like to employ my services in any shape or form please get in touch

Pancakes

Ingredients

• 1 cup flour
• 1 tsp baking powder
• 2 eggs
• 1/5 cup sugar
• 2 tbsp oil (3 desert spoons)

Directions

• Add flour to bowl
• Add sugar to bowl
• Beat eggs in a separate bowl
• Add oil and milk to eggs
• Add liquid ingredients to dry ingredients
• You are aiming for a runny batter consistency. If it is too sticky add milk, too watery add more flour. However, if you have followed the instructions above you should be fine.
• Heat up the non-stick frying pan to medium to high heat.
• Drop spoonfuls of the mixture in to form pancakes.

Look for bubbles

• Flip over with a spatula after roughly 1-2 minutes. Look for bubbles, lift up with pancake with a knife to peek underneath.

Have a peek

Fliptastic

ENJOY!

Heroku recently went live with a git-based deployment cloud hosting solution for rails applications. (mouthful!)

I recently bought a new camera and had the need for a daily uploader to flickr. Heroku have a free plan which is exciting as it essentially means that you can now reliably host a simple rails application for free.

However, there are a few barriers to entry and things to be aware of.

Git

You need to have a working knowledge of git the distributed version control system. This has an initial steep learning curve but once master is a power tool in your arsenal. The heroku documentation is a good place to start.

File Uploads

The filesystem is read-only, this means you have only one option when it comes to uploaded assets. They need to be stored elsewhere, ideally on a CDN. I used Amazon S3 which is not strictly a CDN but can be configured like so if you use Amazon Cloudfront

Heroku Platform

Spend some time reading the documentation so you know how to do things like:

• database migrations
• packaging gems
• running crons
• adding custom domains

Email

Heroku do not provide email for free accounts so if your application needs to work with email you need to outsource your email.

The best place to outsource your email in my opinion is Google Apps for your domain. You can use the action_mailer_tls plugin to interact with google in a fairly reliable manner.

Alternatives

The big alternative in the free hosting arena is google app engine (GAE). It is possible to install ruby apps on there now, and I am keen to try it out.

There is an interesting performance comparison of Slicehost vs Heroku vs Google App Engine for a simple sinatra application.

Overall, I think that heroku is amazing for hosting those simple ‘toy’ rails apps that you dont want to spend money hosting. The pay plans are a little overpriced in my opinion as they still do not compete with the price of a VPS. I would like to see how heroku copes with high traffic sites and if the platform opens up with the paid plans, eg ability to run a postfix mail server.

However, it needs to be noted in terms of heroku costings, you do not need to concern your self with system administration tasks. Although you pay more for hosting you may save a lot in man hours.

Benchmarks

I have done some basic benchmarks using httperf a great tool provided by Hewlett Packard.

Currently we have Heroku free plan versus slicehost 256mb slice running one thin instance behind nginx and mysql server on the same machine. (A cheap setup.)

I hoped to deploy the application to google app engine but it seems like getting rails applications running on this platform is currently a bit of an effort. You also need to almost design your application for the restrictions imposed by the platform. I dont like platform restrictions; while they are likely there to help large applications scale, it serves to cripple the small lightweight app.

For example, there is a 1000 file limit for GAE apps which you can easily reach with a rails app.
It is also not possible to use ActiveRecord as the database provided (BigTable) is a key/value store.

However, running something like sinatra with Datamapper as an ORM is a valid choice for a GAE deployment.
A great blog post on setting up a sinatra app with GAE.

Heroku – 58.5 requests per second stddev=3.6
Slicehost – 47.9 requests per second stddev=2.1

Surprisingly Heroku is faster than the equivalent setup on a small VPS. However, on testing earlier in the day I only managed a maximum of 25 req/s average. This means that you may be subject to competition for resources which are beyond your control.. a little like being on a shared server.

This snowboarding film coming out next year looks really interesting. Apart from filming, there was no use of helicopters and the riders are hiking their own lines. Alaska is calling!