Rails - etags vs. page caching (file cache)

What would be some advantages of using etags/stale?/fresh_when? instead of page caching (on a file cache)?

Apache automatically handles etags for static files, but even if it didn't, page caching would still be better since the Rails app doesn't even get called.

So, in what instances would I use the methods provided by Rails (stale?/fresh_when?)?

From stackoverflow Ivan

• One thing that comes to mind is that fresh_when will still save you some rendering even if you cleared the entire page cache. Here you'd be using both in tandem.

  I'm curious about other answers as well.

  From kch

• Another use that occurred to me was that you could still process some information before letting Rails hand out the "304 Not Modified" header. Like if you want to record hits to a page.

  From Ivan

• They are really complimentary. Etags/fresh_when etc. help you play nice with downstream caches (like your own Varnish/Squid instances or Rack::Cache or the Browser cache or ISP Proxy Servers…)

  Page caching saves you from hitting your rails stack entirely because Apache/your webserver serve the file, so no DB lookups are done. But you have to deal with cache expiration to keep the cache fresh.

  Using etags/conditional get, you don't save much processing time since you still need to to get all the records used on the page:

  def show
    @article = Article.find(params[:id])
    @feature = Feature.current
    fresh_when :etag => [@article, @feature] 
  end
  

  in the case that the user has a current page, it saves you some rendering time and the bandwidth required to send down the page.

  From gerrit