Posts tagged ‘ assets’

Pre-Compiling Assets on Edge

One of the more interesting new features included in Rails 3.1 is the asset pipeline, and a lot of the customization improvements in Spree are enabled by this feature. While the asset pipeline provides excellent flexibility and improved organization for all of Spree’s assets (images, javascripts and stylesheets) it does add a significant overhead as all asset requests are now being handled by Rails itself (and not being handed off to the web server).

This can be especially noticeable in development mode when using a single process application server like Webrick. We’ve recently update the edge version of Spree to include a small tweak to the standard pre-compiling rake task that allows pre-compiling of assets in development mode.

Pre-compiling in production

Rails supports pre-compiling of assets which is intended to offload the overhead of generating and serving assets from the application server in production environments.

Pre-compiling is not required for the asset pipeline to function correctly in production, if you choose to not pre-compile Rails will generate each asset only once and serve each subsequent request using Rack::Cache.

Rack::Cache is generally sufficient for lower traffic sites, but pre-compiling will provide some additional speed increases by allowing the web server to serve all assets, including gzipped versions of javascript and css files.

To pre-compile assets for production you would normally execute the following rake task (on the production server).

$ bundle exec rake assets:precompile

This would write all the assets to the public/assets directory while including an MD5 fingerprint in the filename for added caching benefits.

In production all references to assets from views using image_tag, asset_path, javascript_include_tag, etc. will automatically include this fingerprint in the file name so the correct version will be served.

Pre-compiling for development

Spree alters the behaviour of the precompile rake task so when you execute it passing the RAILS_ENV environmental variable, as follows:

$ bundle exec rake assets:precompile RAILS_ENV=development

It will still output the assets to public/assets but it will not include the MD5 fingerprint in the filename, hence the files will be served in development directly by the web server (and not processed by Rails).

Using the precompile rake task in development will prevent any changes to asset files from being automatically loaded in when you reload the page. You must re-run the precompile task for changes to become available.**

Rail’s also provides the following rake task that will delete the entire public/assets directory, this can be helpful to clear out development assets before committing.

$ rake assets:clean

It might also be worthwhile to include the public/assets directory in your .gitignore file.

This project is maintained by a core team of developers and is freely available for commercial use under the terms of the New BSD License.