Using YUICompressor with Capistrano and Rails 2.3+ on Combined Javascript and CSS
YUICompressor is a standalone Javascript and CSS minifier from the YUI folks. It’s fairly awesome in that it does deep analysis of Javascript using Rhino (a standalone Javascript interpreter). Most minifiers take the low road and merely remove spaces and newlines, and, if you’re lucky maybe shorten the variable names. YUICompressor one-ups them all because it actually parses all your JS and aggressively optimizes it for download speed.
CSS and Javascript Conflation
The problem is most of the guides out there for integrating YUICompressor with Capistrano and Rails are woefully out-of-date. The main issue is that Rails now has built-in support for combining all JS files into a single file. So, there’s no need to manually do this in Capistrano these days.
You can make Rails combine automatically combine your Javascript by adding a :cache => "cache/all" to your javascript_include_tag and stylesheet_link_tag in your layout.
<%= stylesheet_link_tag 'one', 'two', :cache => "cache/all" %>
<%= javascript_include_tag 'jquery', 'ninja', :cache => "cache/all" %>
Priming the JS and CSS Caches
The Capistrano stuff is a bit tricky because Rails doesn’t generate the Javascript and CSS until after the app has been visited for the first time. So, you have to visit each of your web servers after restart during your deploy.
task :after_restart, :roles => :web do
desc "Visiting each web server"
sleep(5) # Wait for passenger to fully spin-up
run "/usr/bin/wget -O- http://127.0.0.1 >/dev/null 2>&1"
end
Invoking YUICompressor
Now, we can invoke YUICompressor after after_restart. The previous after_restart task automatically gets invoked after the web servers are restarted, however, the compression needs to happen after that. So, you have to manually chain a minify just after after_restart.
after "deploy:after_restart", "deploy:minify"The actual task is quite simple for running the compressor itself. It’s just a normal Capistrano task.
task :minify, :roles => :web do
desc "Minify JS and CSS Using YUICompressor"
javascript = "#{current_path}/public/javascripts/cache/all.js"
stylesheet = "#{current_path}/public/stylesheets/cache/all.css"
compressor = "java -jar /usr/lib/java/yuicompressor-2.4.2.jar"
run "#{compressor} --type js #{javascript} -o #{javascript}"
run "#{compressor} --type css #{stylesheet} -o #{stylesheet}"
end
Trackbacks
Use this link to trackback from your own site.
Awesome post, works like a charm! One question, I have a testing server that runs in development mode. So caching is not enabled, do you know how I can test for the cach/all file before running yui compressor? otherwise it gives me some ugly java file not found exceptions when deploying to testing
Why not just minify the pre-cached files, then let Rails concatenate the minified files? I tried this and the difference in size of the final *.js file was insignificant.
The size between minify.rb and yuicompressor.jar wasn’t noticeable? Probably not if you don’t have a lot of JS.
As for letting Rails perform the concatenation, isn’t that what < %= javascript_include_tag 'jquery', 'ninja', :cache => ‘all’ %> does?
The wget business is due to weird issues with our load balancer. This was necessary to force Rails running on Phusion Passenger to perform the concatenation on all of our production servers.
Sorry, I didn’t mean minify.rb. What I’m talking about is the difference between the simple flow:
yuicompressor -> Rails concatenate
Versus the more complicated flow described in this blog post:
Rails concatenate -> yuicompressor
There is a lot of extra work here to reverse the natural order of these two steps and get Rails to concatenate first. Waiting for the server to restart, wget, etc. It’s messy. And — perhaps more importantly — the compression step really should be done before deploy:symlink. Otherwise you risk the server sending uncompressed js to an end user, or even worse: if the server happens to read the file at the same time as yuicompressor is writing it, it could send a partial js file.
My point is the difference in the size of the final *.js file is insignificant. Literally just a few bytes, including all of Prototype and Scriptaculous.
I tried to diff them but since each file is one huge line, it was not really possible to see the difference, but I suspect the only difference is that the more complicated flow eliminates the newlines between the concatenated files. Hardly worth the added complexity and risk.
Here’s my recipe to compress each js and css file. [I hope the formatting works...]
after “deploy:update_code”, “deploy:minify”
namespace :deploy do
task :minify, :roles => :web do
def go(ext, path)
compressor = “java -jar /opt/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar”
path = File.join(release_path, “public”, path)
run “for i in #{path}/*.#{ext}; do #{compressor} –type #{ext} -o $i $i; done”
end
go ‘js’, ‘javascripts’
go ‘css’, ‘stylesheets’
end
end
Oh, right. That would work too. I can see your risk argument though. YUICompressor could theoretically cause a problem by sharing variables names from code that was never meant to be shared. To be honest though, I never had a problem with that particular one.
I didn’t intend to make such an argument (about yuicompressor sharing variables names) and I’m pretty sure yuicompressor does not have a problem with that.
The risk comes from running yuicompressor on live files. Capistrano is designed to prepare the entire directory first, then switchover in a flash by changing the symlink. What you’re advocating in this post goes outside that philosophy by modifying the files in the currently running application.
Oh, right. Technically, the files aren’t live until the application is pushed. And, while the application is being restarted, maintenance.html would be displayed.
If you’re deploying a high traffic site, I can see this perhaps being a slight issue. However, in that case, you’d probably have a staging server for CruiseControl and Selenium/screw_unit (or equivalent) which would mitigate the particular risk of live files not being tested before they were put into production.
I agree that if you don’t have a staging environment, performing concatenation before minify could be a tad risky. In that particular case, doing minify first would be more desirable.
I still don’t understand your defense of this scheme. I say that doing minify first is *always* more desirable. It is less complex, and less risky. What are the drawbacks? A few tiny bytes? Why would you ever want to go to the extra trouble and risk for that?
Your minify/concatenation scheme works too. My method is in use across a few high-traffic sites and seems to be working fine too. I could go either way. If you’re having a problem with concatenating then minifying, then, by all means, do the minify first.
I changed the run command in Scotts minify task to process files in subdirectories as well (e.g., as in public/stylesheets/blueprint/):
run “find #{path} -name *.#{ext} -exec #{compressor} -o {} {} \\;”
Thanks! Good post! I follow the order scott suggested. But the post was very helpful! I minified the scripts after symlink and before restart.
after “deploy:symlink”, “deploy:minify”
Thanks for sharing this. I found another good article which also talks about uploading the static contents on Amazon S3.
http://www.makeurownrules.com/ruby-on-rails/minify-compress-synch-amazons3-capistrano