Client-side caching in Rails: conditional GET requests
Tags: beginners, rails, optimization, caching
Published: 2018-05-02 13:55:07

---
title: Client-side caching in Rails: conditional GET requests
published: true
description: Rails' conditional GET support allows you to store rendered pages in the user's browser cache to reuse them for repeated requests instead of rendering the same view multiple times.
cover_image: https://blog.appsignal.com/images/blog/2018-05/conditional-get.jpg
tags: beginners, rails, optimization, caching
canonical_url: https://blog.appsignal.com/2018/05/01/client-side-caching-in-rails-conditional-get-requests.html
---


Besides [Russian doll caching](https://blog.appsignal.com/2018/04/03/russian-doll-caching-in-rails.html), there are more techniques to speed up performance in Rails apps. This time we'll look at Rails' built-in conditional GET support, which allows you to store rendered pages in the user's browser cache.

## The Etag and Last-Modified headers

When your browser executes an HTTP GET request for a page in your Rails app, the router will link it to one of your controller actions. The controller will then request the required data from the database and render the view. An HTTP response (with `200 OK` as the response code) is then sent back to the browser with the rendered HTML from the view in the response's body for your browser to parse and display.

When the resource is requested again, we'll go through the same pipeline. In some situations, this is unnecessary because the page didn't change in the meantime. For that, HTTP offers its *ETag* and *Last-Modified* headers. Using these, the browser can store the response body, and use the headers to invalidate them when they become stale.

*Etags*, or *Entity tags*, are used for client-side cache validation, so you can think of them as cache keys for your HTTP responses. They're passed back to the browser in the HTTP response header for every request.

    ~ $ curl -I http://localhost:3000/products/1
    HTTP/1.1 200 OK
    ...
    ETag: W/"9462d76cc55aeb6249fa990e39231c7c"
    Last-Modified: Wed, 25 Apr 2018 08:27:04 GMT
    ...

If the response is repeated later, the browser finds the existing response in its cache and uses the stored Etag from the last request as the `If-None-Match` header. This header will tell our Rails app that we already have this version in the cache.

If the Etag from the request matches the current one, Rails will send a `304 Not Modified` response without a response body. This will tell the browser to use the one from its local cache instead.

    ~ $ curl -i -H 'If-None-Match: W/"9462d76cc55aeb6249fa990e39231c7c"' http://localhost:3000/products/1
    HTTP/1.1 304 Not Modified
    ...
    ETag: W/"9462d76cc55aeb6249fa990e39231c7c"
    Last-Modified: Wed, 25 Apr 2018 08:27:04 GMT
    ...

## Conditional GET requests in Rails

If we request a page from a local Rails application, we can see that Rails adds an Etag for each request automatically. If we request the same page a couple of times in a row, we can see the Etag changes for each request.

While Rails generates an Etag for each request by default, it uses a digest of the whole response body to generate it. This means the [`<%= csrf_meta_tags %>`](http://api.rubyonrails.org/classes/ActionView/Helpers/CsrfHelper.html#method-i-csrf_meta_tags) in the layout throws the Etag off, as the csrf-token meta tag changes for each request. Because that changes the body for each request, the Etag is invalidated and the local cache is marked stale.

Besides that, Rails will never return a `304 Not Modified` by default, because the local cache is never explicitly marked as fresh in our controller.

## `fresh_when` and `stale?`

To use Etags from the request header for conditional GETs, we need to explicitly mark an object in the local cache as "fresh". For example, for a page that shows a product, we can keep the cache fresh as long as the product and the view templates don't change.  To make that work, we'll do two things.

1. We'll explicitly set values that will make up our Etag, as using the whole response body would require us to render the whole body to check if the cached response is valid, which negates the speedup from caching the page locally.
2. We'll compare the Etag from the request header to one we predict *before* rendering the view, and we'll omit the rendering if they match.


Rails comes with helpers that does everything for us. We can explicitly base the Etag and Last-Modified date on the product by using [`fresh_when`](http://api.rubyonrails.org/classes/ActionController/ConditionalGet.html#method-i-fresh_when).

``` ruby
# app/views/products/show.html.erb
def show
  @product = Product.find(params[:id])
  fresh_when @product
end
```

If you have an explicit `respond_to` block, use [`stale?`](http://api.rubyonrails.org/classes/ActionController/ConditionalGet.html#method-i-stale-3F) instead of `fresh_when`.

``` ruby
# app/views/products/show.html.erb
def show
  @product = Product.find(params[:id])

  if stale?(@product) 
    respond_to do |format|
      format.html
    end
  end
end
```

Now, requesting one of the product pages will cache the response locally. Any subsequent requests to the same page will include the Etag to tell Rails we have a cached response, which is then compared to the new Etag. If that matches, Rails will skip rendering the page, and return a `304 Not Modified` immediately.

![A view with conditional GET requests](https://blog.appsignal.com/images/blog/2018-05/conditional_get.jpg)

*Note*: Refreshing the page will always request an uncached version of the page. To test if your conditional GETs work, navigate away using a link or using the back button instead.

How did you like this article and previous articles in the [AppSignal Academy series](https://blog.appsignal.com/category/academy.html)? We have some more articles about caching in Rails lined, up, but please don’t hesitate to [let us know](https://twitter.com/appsignal) what you’d like us to write about (caching-related or otherwise) next!