Heroku rails 3.1 app - compiling assets locally vs compiling assets during slug compilation

13
votes

I'm running a rails 3.1 app on Heroku Cedar stack which supports the asset pipeline. Heroku lists 3 ways to compile assets

  1. Compiling assets locally.
  2. Compiling assets during slug compilation.
  3. Compile assets during runtime.

Obviously #3 is bad for performance and Heroku docs also recommend against it. But I'm not sure which is better between #1 and #2.

#1 requires that you run rake assets:precompile and include your public/assets folder in git. Your slug will be bigger but I assume the downtime for deploying a site will be lower. But bigger slug size means slower app startup so maybe it's a wash.

#2 will make it take longer to deploy updates because of precompile being done on Heroku side. However, you will have a smaller slug and there's less to manage/remember.

My question is - which option (#1 or #2) is the best for production and why?

So far it looks like option #2 but I want to make sure I'm not overlooking something.

2
ruby-on-railsrubyruby-on-rails-3herokuasset-pipeline
devcenter.heroku.com/articles/cdn-asset-host-rails31 is a good read too - although it syncs assets to S3 from your app on Heroku so they are still present in your slug just not served from Heroku. – John Beynon
also sometime #2 isn't always an option. Heroku would always try to compile them during slug compilation first and if then fails do then at runtime. – John Beynon

2 Answers

7
votes

I addressed some of these issues and a big gotcha in my question here: Rails 3.1.1 asset pipeline Heroku caching gotcha

I'd prefer #2 if it worked for me so I don't have to checkin compiled assets which just bloats the git repository.

Compiling assets during slug compilation won't result in any additional downtime because your existing app will stay up until slug compilation is complete so no worries there.

My advice would be #2 if you can make it work for you. If you do end up going w/ #1 then take best practice would be to git rm -r public/assets before rake assets:precompile to make sure no cruft remains.

2
votes

It could depend on the size of your asset folder, (and maybe a long term solution would be to put those assets outside the application and host them on S3 or the like.)

Otherwise, I am supposing #1 would be the best on production since any asset can be used and cached straight away.

I am reading Heroku's documentation section on assets, and they seem to indicate that #2 would be used just in case you have forgotten to do it yourself, as a convenience. You will not get a small slug, since the results of asset preparation will be included in the slug to deploy itself.