Nobody likes waiting for a web page to load. Pity, then, the Ruby on Rails developer, proud of the the development platform’s famous efficiency of code, combating the slanderous claims of a slow production environment, and then condemned to watch the browser bar spinning and spinning for the 500th time during today’s coding session. Because Rails requests in the default development environment are s l o w.
Why? By default, every web page request is verifying and recompiling every referenced asset — every Coffeescript, Sass, and Less file. Ajax requests with responses that don’t include the application layout (and its application.js and application.css manifest file burdens), are delightfully zippy, but loading a simple home page? Over and over throughout the course of the day? Goodbye delight and efficiency.
Until you make one simple change in development.rb:
# Expands the lines which load the assets config.assets.debug = <strong>false</strong>
In trade for the speedup, disabling asset debugging will replace detailed asset syntax error exception pages like:
Sass::SyntaxError in Home#index
Showing app/views/layouts/application.html.erb where line #9 raised:
Invalid CSS after "}": expected selector or at-rule, was "}" (in app/assets/stylesheets/application.css.scss)
Extracted source (around line #9): etc.
And instead of each individual asset files downloaded to the browser, like:
you’ll only see your manifest files:
Those are minor downsides for having far faster refresh cycles. If you want to be able to re-enable asset debugging for individual requests, you can use the
debug option of
will debug the application.js manifest when either is true:
- asset debugging is configured
?jsdebug=trueis appended to a URL in the development environment
Use a similar construct on
<%= stylesheet_link_tag "application" %> with a parameter like
cssdebug. Then, rather than slowing down every request for debug info, you can quickly enable it from the browser only when necessary.
Asset logging off
When assets are requested by the browser, those requests are logged in voluminous detail in the output of
rails server. You’ve probably noticed pages of messages like this one scrolling up in your terminal at every request:
Started GET "/assets/application.css" for 10.0.2.2 at 2012-12-13 21:33:05 +0000 Served asset /application.css - 304 Not Modified (17ms) cache: [GET /assets/application.js] stale, valid, storecode>
These extraneous log messages are reduced to just the asset manifests by turning asset debugging off, but you can minimize them even further to de-clutter the development server log. The discussion of Rails bug 2639 offers several approaches, but the easiest is simply adding the newly released disable_assets_logger gem to your Gemfile:
gem "disable_assets_logger", "> 1.0.0", group: :development
The cache-related log lines will still appear, but the other lines are exiled to
Disabling asset debugging still requires that assets be compiled for each request. I consider that a good thing in general, but some developers find a speed advantage in the development environment by precompiling assets:
$ RAILS_ENV=development bundle exec rake assets:precompile
$ rake assets:clean $ rm -r public/assets
but in practice I’ve had to ferret out precompiled files from caches and tmp directories, which outweighs any speed savings.
There are also a few gems available that purport to speed up the request process in the development environment, although in my brief experiments with them they haven’t provided enough of a speed advantage to make up for any inherent disadvantages, additional code requirements, or configuration time.
- rails-dev-boost: reduces the frequency with which Ruby files are reloaded in response to requests
- rails-dev-tweaks: prevents asset requests from reloading Ruby files