IT Really Matters

// drunk, fix later

// somedev1 - 6/7/02 Adding temporary tracking of Login screen
// somedev2 - 5/22/07 Temporary my ass

// I dedicate all this code, all my work, to my wife, Darlene, who will
// have to support me and our three children and the dog once it gets
// released into the public.

// sometimes I believe compiler ignores all my comments

Fast page loads are very important when developing web applications. I want to get almost immediate feedback when changing code by refreshing the page in my browser. Rails makes it better by performing many smart automatic reloading techniques for files in development environment. However there can be many different factors slowing down the loading of the page. One of the factors is a lot of assets, especially if they’re external dependencies. In this post i’m going to demonstrate how to organize assets in a clever way to make Rails application development more efficient by not waiting so much after each browser refresh.

Creating the App

Let’s create a simple Rails 3 app to demonstrate the issues i mean:

Let’s create the Slow controller:

Fire it up!

Let’s open up http://localhost:3000/slow/index in the browser. It takes about 300-400ms when looking at Chrome’s networking tab. Not too slow, is it?

Making it All More Slower Lifelike

Let’s make the app more real by adding some external JavaScript and CSS dependencies - for example jQuery UI and Bootstrap.

Our application is now ready for conquering the world, but it is damn slow in development mode. For me, the page load time increased in the fold of 10 - from ~300ms to 3sec.

Analyzing the Problem

This is what i see on the Chrome’s Network tab:

A lot of assets! A total of 58 requests were performed to load the page. It does not improve much even if i switch WEBrick against Thin. The problem is that there’s too many requests which should not happen at all.

Making it Faster

One way Rails makes itself faster in production is concatenating all assets into one external file (and possibly compress them). In this way browser needs to perform less requests making the page load faster.

In development we usually want to get separate asset files and not compress them to make it easier to debug. But how often do we need to debug external dependencies instead of our own code? Not too often, i suspect. Why not move all external assets into a single file then? If we’d do that then the browser would need to make less requests. As an added bonus it will cache these files more efficiently too since they are not often changed. Even in production, the probability that external dependencies have been changed between deployments are slimmer, which means that users do not have to download all these external assets after each re-deployment since the asset’s fingerprint will be the same.

Splitting Things Up

To move external dependencies into a separate files from our own code we need to perform some small steps.

First, move dependencies away from application.js and application.css:

Now there’s an application.{js|css} and vendor/assets/{javascripts|stylesheets}/vendor.{js|css} files.

Add them into the layout so browser knows to load them:

Let’s hit refresh in the browser and check out the results. It does now two more requests due to the vendor.{js|css} files.

Perform Less Requests and Be Faster, Rails!

We need to tell Rails to not split vendor files into separate requests, but rather concatenate everything in these files into one file. To do that we need to add :debug => false as a parameter for the layout link helper methods. This is how the layout file should look like after that change:

Let’s hit refresh in the browser and see the results:

There are only 9 requests performed and they all fit on the image above. Load time is again under a second. Now try to think how many times per day do you press refresh in your browser to see the changes you’ve made and calculate the time wasted for waiting after the browser.

Precompiling Assets in Production

When precompiling assets in production environment then you also need to precompile vendor files. For this to happen add a line to the Rails configuration:

Conclusion

Do not only pay attention to the performance of your application when it is running in production, but care for the speed of development as well. After all, if it is slow, then you’re less efficient. And less happy - at least you should be if you care - otherwise software development might not be the profession for you.

This simple trick helps me to feel better after each day of hard work. How do you feel?