Fragment caching in Ruby on Rails - Deep Dive

Overview - Fragment caching

What is it?

Fragment caching is a technique in Rails that stores parts of a web page separately to speed up page loading. Instead of rebuilding the whole page every time, Rails saves small pieces called fragments and reuses them. This helps especially when some parts of the page change often while others stay the same. It makes websites faster and reduces server work.

Why it matters

Without fragment caching, every time someone visits a page, the server must recreate the entire page from scratch, even if most parts haven't changed. This wastes time and computing power, making websites slower and less responsive. Fragment caching solves this by remembering and reusing stable parts, improving user experience and saving resources.

Where it fits

Before learning fragment caching, you should understand basic Rails views and how rendering works. After mastering fragment caching, you can explore other caching strategies like Russian doll caching and low-level caching to optimize performance further.

Mental Model

Core Idea

Fragment caching saves and reuses small parts of a web page to avoid rebuilding them every time, making page loading faster.

Think of it like...

Imagine you are making a sandwich every day. Instead of making the bread from scratch each time, you bake a batch once and store the slices. When you want a sandwich, you just grab the stored bread slices and add fresh ingredients. Fragment caching is like storing those bread slices to save time.

┌─────────────────────────────┐
│ Full Web Page Rendering      │
├──────────────┬──────────────┤
│ Fragment A   │ Fragment B   │
├──────────────┼──────────────┤
│ Cached      │ Rebuilt      │
│ (saved)     │ (new build)  │
└──────────────┴──────────────┘

When a page loads:
- Use cached Fragment A
- Rebuild Fragment B
- Combine both to show full page

Build-Up - 7 Steps

1

Foundation

What is fragment caching in Rails

Concept: Introduce the basic idea of fragment caching as storing parts of a view to reuse later.

In Rails, views are templates that create HTML pages. Fragment caching lets you save a part of this HTML output so Rails can reuse it instead of recreating it every time. You wrap the part you want to cache inside a cache block in your view code.

Result

Rails stores the HTML output of the wrapped part and reuses it on future requests, speeding up page rendering.

Understanding that you can cache parts of a page, not just whole pages, opens up flexible ways to improve performance.

2

Foundation

How to use cache blocks in views

Concept: Learn the syntax and placement of cache blocks in Rails views.

You use the `cache` helper in your view files like this: <% cache do %> <% end %> Rails will save the output inside this block. Next time, it will serve the saved content instead of running the code inside again.

Result

The wrapped HTML or partial is saved and reused, reducing rendering time.

Knowing the exact syntax and how to wrap parts of your view is essential to start caching effectively.

3

Intermediate

Using cache keys for dynamic fragments

🤔Before reading on: do you think fragment caches update automatically when data changes, or do you need to tell Rails when to expire them? Commit to your answer.

Concept: Introduce cache keys to control when cached fragments should be refreshed based on data changes.

Rails uses cache keys to know when to reuse or refresh a cached fragment. You can pass an object or a custom key to the cache helper: <% cache @product do %> <% end %> Rails uses the product's cache key, which changes when the product updates, to expire the cache automatically.

Result

Cached fragments update automatically when the underlying data changes, keeping the page fresh.

Understanding cache keys prevents showing outdated content and reduces manual cache management.

4

Intermediate

Combining fragment caching with partials

🤔Before reading on: do you think caching a partial multiple times with different data creates one cache or multiple caches? Commit to your answer.

Concept: Learn how fragment caching works with partial views and multiple instances.

When you cache a partial that renders multiple items, Rails creates separate caches for each item based on their cache keys: <% @products.each do |product| %> <% cache product do %> <%= render product %> <% end %> <% end %> Each product's fragment is cached separately, so updating one product only refreshes its cache.

Result

Efficient caching of lists where only changed items are rebuilt, saving time and resources.

Knowing that caches are per item avoids unnecessary full list cache expiration.

5

Intermediate

Cache expiration and manual control

Concept: Understand how to expire cached fragments manually when needed.

Sometimes you want to clear a cached fragment before it expires automatically. You can use Rails cache methods in controllers or background jobs: Rails.cache.delete(fragment_cache_key) You need to know the exact cache key to delete the fragment. This is useful when data changes outside normal update flows.

Result

You can force cache refreshes to keep content accurate when automatic expiration isn't enough.

Knowing manual cache control helps handle edge cases where automatic expiration fails.

6

Advanced

Russian doll caching with nested fragments

🤔Before reading on: do you think nested cached fragments rebuild all inner caches when the outer cache expires, or only the changed parts? Commit to your answer.

Concept: Learn how nested fragment caches work together to optimize complex views.

Russian doll caching means caching fragments inside other cached fragments: <% cache @product do %> <%= render 'product_details' %> <% cache @product.reviews do %> <%= render @product.reviews %> <% end %> <% end %> When the outer cache expires, Rails reuses inner caches if they are still valid, saving work.

Result

Highly efficient caching where only changed parts are rebuilt, even in nested views.

Understanding nested caching prevents unnecessary work and improves performance in complex pages.

7

Expert

Cache key generation and pitfalls

🤔Before reading on: do you think Rails cache keys include timestamps by default, or do you need to customize them? Commit to your answer.

Concept: Explore how Rails generates cache keys and common mistakes that cause stale or missing caches.

Rails generates cache keys using the object's class, id, and updated_at timestamp by default. If updated_at is missing or not updated properly, caches may not expire when expected. Custom cache keys can be created: cache ['v1', product, product.updated_at.to_i] do ... end This ensures cache freshness. Also, beware of using non-unique keys that cause cache collisions.

Result

Reliable cache expiration and avoidance of stale or overwritten fragments.

Knowing cache key internals helps avoid subtle bugs that cause users to see outdated or wrong content.

Under the Hood

When Rails renders a view with fragment caching, it checks if a cached version of the fragment exists in the cache store (like memory or disk). If found, it serves the cached HTML directly, skipping rendering code inside the cache block. If not found, it runs the code, saves the output in the cache store with a key, and serves it. Cache keys often include object identifiers and timestamps to detect changes. The cache store manages storage and expiration based on these keys.

Why designed this way?

Fragment caching was designed to balance performance and freshness. Caching entire pages is fast but inflexible. Caching small parts allows Rails to reuse stable content while updating dynamic parts. Using cache keys tied to data changes automates expiration, reducing manual work. This design fits Rails' philosophy of convention over configuration and developer productivity.

┌───────────────┐
│ Render Request│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Check Cache   │
│ for Fragment  │
└──────┬────────┘
       │Cache Hit?
   ┌───┴─────┐
   │         │
  Yes       No
   │         │
   ▼         ▼
Serve     Render
Cached    Fragment
HTML      and Store
          in Cache
           │
           ▼
       Serve HTML

Myth Busters - 4 Common Misconceptions

Quick: Does fragment caching automatically update cached parts whenever any related data changes? Commit to yes or no.

Common Belief: Fragment caching always updates automatically whenever any data changes.

Reality: Fragment caching updates only when the cache key changes, which depends on how you set it. If the cache key does not reflect data changes, the cache may serve stale content.

Why it matters: Assuming automatic updates can cause users to see outdated information, leading to confusion or errors.

Quick: Do you think caching a fragment means the entire page is cached? Commit to yes or no.

Common Belief: Caching a fragment caches the whole page.

Reality: Fragment caching only caches the specific part wrapped in the cache block, not the entire page.

Why it matters: Misunderstanding this can lead to wrong assumptions about performance gains and cache behavior.

Quick: Do you think nested fragment caches always rebuild all inner caches when the outer cache expires? Commit to yes or no.

Common Belief: When an outer cache expires, all nested caches inside it are rebuilt regardless of their state.

Reality: Nested caches are independent; if inner caches are still valid, Rails reuses them even if the outer cache expires.

Why it matters: Knowing this helps optimize caching strategies and avoid unnecessary rendering.

Quick: Do you think using the same cache key for different fragments is safe? Commit to yes or no.

Common Belief: Using the same cache key for different fragments is fine and saves space.

Reality: Cache keys must be unique; reusing keys causes cache collisions and wrong content to be served.

Why it matters: Cache collisions can cause confusing bugs where users see incorrect page parts.

Expert Zone

1

Rails cache keys rely heavily on the updated_at timestamp; missing or incorrect timestamps cause stale caches that are hard to debug.

2

Fragment caching works best combined with Russian doll caching to minimize redundant rendering in nested views.

3

Cache stores differ in performance and persistence; choosing the right store (memory, file, Redis) affects cache speed and durability.

When NOT to use

Fragment caching is not ideal for highly dynamic content that changes every request or user-specific data. In such cases, consider low-level caching, HTTP caching, or client-side rendering instead.

Production Patterns

In production, developers use fragment caching with cache versioning to handle schema changes, combine it with background jobs to expire caches asynchronously, and monitor cache hit rates to optimize performance.

Connections

Memoization

Similar pattern of storing results to avoid repeated work

Understanding fragment caching helps grasp memoization, as both save expensive computations for reuse.

Content Delivery Networks (CDNs)

Builds on caching concepts but at the network edge

Knowing fragment caching clarifies how CDNs cache whole pages or assets closer to users to speed delivery.

Database Indexing

Both optimize performance by avoiding repeated full work

Recognizing caching as a way to avoid repeated rendering is like indexing avoids scanning entire tables, improving speed.

Common Pitfalls

#1 Caching fragments without proper cache keys causes stale content to show.

Wrong approach:

<% cache do %>
<%= @product.name %>
<% end %>

Correct approach:

<% cache @product do %>
<%= @product.name %>
<% end %>

Root cause:

Not providing a cache key means Rails cannot detect when the data changes, so it never expires the cache.

#2 Using the same cache key for different fragments causes wrong content to appear.

Wrong approach:

<% cache 'sidebar' do %>
Sidebar content A
<% end %>

<% cache 'sidebar' do %>
Sidebar content B
<% end %>

Correct approach:

<% cache 'sidebar_a' do %>
Sidebar content A
<% end %>

<% cache 'sidebar_b' do %>
Sidebar content B
<% end %>

Root cause:

Cache keys must be unique to avoid collisions; reusing keys overwrites cached fragments.

#3 Expecting cached fragments to update immediately after data changes without cache expiration.

Wrong approach:

Update @product in database but do not expire cache or update cache key.

Render page expecting fresh data.

Correct approach:

Ensure @product.updated_at changes or manually expire cache after update.

Then render page to see fresh content.

Root cause:

Cache expiration depends on cache keys; if keys don't change, cache stays stale.

Key Takeaways

Fragment caching stores parts of a page separately to speed up rendering by reusing stable content.

Cache keys control when cached fragments expire and must reflect data changes to avoid stale content.

Nested fragment caching (Russian doll caching) optimizes complex views by reusing inner caches when possible.

Manual cache expiration is sometimes necessary to keep content fresh beyond automatic expiration.

Understanding cache key generation and uniqueness prevents subtle bugs and cache collisions.