I also think it's a bad idea to enable asset compilation in production. From the Rails asset guides (http://guides.rubyonrails.org/asset_pipeline.html#live-compi...):
"This mode uses more memory, performs more poorly than the default and is not recommended."
Your strategy of using two JS scripts per view, one site-wide and one page-specific is interesting. I wonder how to test the performance to really determine the value. Maybe look at time-to-render?
Then I have an application level CSS&JS that has everything generic in it. This is for a reasonably big app, so the overhead of having a single CSS/JS isn't insignificant - particularly when supporting mobile devices.
The other useful thing is a I as a dasherized version of the controller name and action to the body tag - as an id and a class respectively. So the body tag is something like
<body id='my-controller' class='show'>
These constructs are to be used sparingly -- you don't want to mash everything together too much -- but they're very handy when used right.
One other optimization you may want to talk about in your next article is to use a gem like the asset_sync gem to upload your assets to S3 or CloudFront (or similar) at compile time.
On these occassions the hit to download JQuery (or something big like JQueryUI) is zero.
This is more a consideration for a landing page than a heavy-use application though.
I don't see where the article recommended that. The article (and the Rails Guides) seem to be pre-compiling for production. This is the standard & recommended practice.
- number of $(document).ready() callbacks that check whether the current file should run within the single application.js approach. This could grow to be an issue with much larger apps.
- how often the application.js file gets invalidated by a deploy (if it is every deploy this may be annoying for users if there's always a large performance penalty on the first download - especially for apps where the usage isn't regular).
- in the 2 scripts version it's very unlikely that the heavyweight application.js global file will get invalidated regularly, but it is likely that several of the smaller specific page js files will get invalidated with each deploy.
I guess the question is whether downloading several smaller files for each deploy beats downloading the whole application.js file for each deploy (network overhead being the likely bottleneck here).