Cache headers in Rails?

Out of the box, Rails 3 provides a simple HTTP caching configuration for static pages and assets. While your application benefits from this setup, specifying appropriate cache headers for all requests, even dynamic ones, can give you an order of magnitude improvement in response times, user experience and resources required to power your application. This article walks through several use cases where utilizing HTTP cache headers in a Rails 3 application can improve response times with minimal modification.

The default configuration of a Rails 3 app includes the use of HTTP cache headers in the most basic of scenarios. Additionally, it comes configured with the asset pipeline for more efficient delivery of static assets and the Rack::Cache and Rack::ETag middleware which together serve as an un-intrusive caching mechanism. Rails 3.1+ introduced the concept of the Asset Pipeline.

Along with the concatenation and compression of JS and CSS assets, Rails added HTTP cache headers to prevent re-fetching identical assets across requests. The Age header conveys the estimated age of the resource from the cache. Etag, computed by rack middleware, based on the response body digest.

For most applications these default values will suffice and no modifications to the asset pipeline are necessary. Rails 3 introduced Rack::Cache as a native proxy-cache. In production mode, all your pages with public cache headers will be stored in Rack::Cache acting as a middle-man proxy.

As a result, your Rails stack will be bypassed on these requests for cached resources. By default Rack::Cache will use in-memory storage. In highly distributed environments such as Heroku a shared cache resource should be used.

On Heroku use Rack::Cache with a Memcached add-on for highly-performant HTTP-header based resource caching. Rack::ETag provides support for conditional requests by automatically assigning an ETag header and Cache-Control: private on all responses. It can do this without knowing the specifics of your application by hashing the fully-formed response string after the view has been rendered.

While this approach is transparent to the application it still requires the application to fully process the request to hash the response body.