Just by building your application with Ruby on Rails 3.1+, there are a number of performance features that you get just by following the Rails conventions. These are features that make your application faster to your users, and faster applications have been shown to have happier users.
And you get them all for Free!
ETags for All Content
Rails adds Rack Middleware for ETag (Rack::ETag) and ConditionalGet (Rack:ConditionalGet) that, together, help to reduce the amount of data that is sent to the client, without you having to do anything (although you can add code to make this work even more to your advantage, which is something I’ll write about later).
Every action that is executed that returns content, and is not marked as ‘no-cache’, will have an ETag generated for it. If a browser requests the same action, and the same content is generated - making the ETags match - then the ConditionalGet middleware will throw away the response you generated and send a Not Modified response instead, as the browser already has that content.
The obvious improvement here is that if you can detect that the content will be the same before you do all the work to generate it, then you can respond to the browser raven sooner! Rails provides a number of ways to do this that I’ll write about later
The Asset Pipeline
One of the best things you can do to improve the performance of your web application is to reduce the number of individual files that the browser has to download. Since Rails 3.1 Rails the Asset Pipeline reduces the number of CSS and JS files downloaded by combining them all into a single file of each type for production, but allowing you to keep functionality in separate files during development.
Unique Asset File Names
The Asset Pipeline system in Rails allows you to automatically add unique identifiers during the Precompile phase (called digests), and then the built-in helpers reference these unique names at runtime without you having to write any special code, other than using the provided helpers.
Why would you do this and not refer to images and other assets directly?
The main reason is that you can now set the caching of these files to be a really long time, since the names of the files will change if you change the content of the files. Typically, this cache setting will be done in Apache or Nginx configuration, but if you’re using Heroku, you should read my recent post on Heroku Configuration for Performance Rails Apps
The longer you can cache images and other assets, the fewer requests a browser needs to make to display your page to your user, and the happier your users will be.
As an extra benefit, the use of a Content Delivery Network to host your assets becomes much easier than with a regular web application if you don’t have to worry about cleaning up cached files when you update them.
Rails 3.1+ provides automatic performance features that you get for free as an application developer
- ETags to get Not Modified to reduce data returned
- The Asset Pipeline to reduce the number of requests per page
- Unique Asset names to allow long cache times and enable CDN usage