What are the performance implications of adding all JQuery code to application.js in a Rails project

Question

I'm running a fairly large web application which contains an increasing amount of JQuery code for both UI polish and making AJAX requests.

Larger chunks of code live in their own, dedicated .js file, but there are an increasing number of pages (primarily forms) which use a small sprinkling of JQuery for showing/hiding form elements, modifying classes etc. Presently I put this code in the $(document).ready() block in my main application.js file.

Given this, on any given page view application.js is loaded and all the JQuery code in this ready() block is executed despite the fact that only one or two calls will be relevant to the current page. Are there any performance implications of doing this or is it actually quite negligible? If there are performance implications, what is the recommended alternative way of managing these page-specific JQuery (or indeed any type of Javascript) snippets in large Rails apps?

Despite being considered bad-practice, wouldn't it make more sense to define simply JQuery rules which are specific only to a single form inside the form partial itself?

Answer 1

If you move all your $(document).ready() blocks to a separate JS file, clients will only download it once, saving them a few kB per request. There are many ways to improve performance and reduce load. Check this out: http://developer.yahoo.com/performance/rules.html and this Firefox extension: http://developer.yahoo.com/yslow/help/index.html

Answer 2

I take it you are concerned about javascript execution performance on the client side?

If the overhead of the javascript execution per page in your $(document).ready() block, is not that high, I would be tempted to not worry about it.

However it is quite possible you could have some pretty heavyweight javscript you only want to run when the relevant forms (or other page elements) have been rendered.

If this is so, what about this as an approach: For each element that has a partnering javascript function that needs calling, set a flag inline.

e.g.

<%= some rails stuff %>
<script type="text/javascript">
   elements_rendered('your_element_name') = true;
</script>

Then in your $(document).ready() block have:

if (elements_rendered('your_element_name'))
    your_function_for_the_element();

I am pretty sure you could wrap this sort of functionality inside your Rails code to largely automate it if you wanted to generalise it.

Answer 3

The advantage of having everything in one file (application.js) is that the client will have cached this file, and it will serve them locally on consequent HTTP requests.

The performance hit you may get is related to your jQuery code itself. Specifically, on searching DOM elements that you later act on. Sizzle, the new selector engine in jQuery 1.3, parses your selectors from right-to-left, just like browsers parse CSS. Therefore it's best to try to narrow down your selection as much as possible on the right of the selector query. jQuery itself is optimized for #id selectors too (skips going through Sizzle), which is good to have in mind. For this reason, doing $('#id').find('div') is much faster than doing $('#id div'). Other than that, most warnings that apply to google page speed regarding CSS selectors will apply to your jQuery selectors.

Regarding page specific js, here's one way to do it:

Add a <%= yield :javascripts %> on your layout, right before your closing body tag. Then you can add this to your view, after your html:

<% content_for :javascripts do %>
  <% javascript_tag do %>
    //your js here
  <% end %>
<% end %>

This saves an HTTP request and keeps your view behavior close to your view which is a win, although it doesn't minify your javascript. That is a compromise that has worked well for me.