A Rails view rendering in 400ms instead of 80ms means lost users and wasted server resources. The culprits are almost always the same: N+1 queries, partials inside loops, missing cache layers, and unindexed columns. Each problem has a well-known fix. The challenge is applying them systematically.
Boost Rails Performance: Master Eager Loading & the load Method
How do you reduce data loads in views?
Efficient views start with fetching only what you need. Two techniques make the biggest difference:
Select only required fields. Instead of Product.all, use Product.select(:id, :name, :price) or Product.pluck(:name, :price) when you only need raw values. This reduces memory consumption and speeds up serialization.
Eliminate N+1 queries with eager loading. Displaying orders with customer names? Without eager loading, Rails runs one query for orders plus one query per customer. Fix it with includes:
# Bad: N+1 queries
@orders = Order.all
# Each order.customer triggers a separate query
# Good: 2 queries total
@orders = Order.includes(:customer).allChoose the right method for the job:
| Method | Use when | Query behavior |
|---|---|---|
includes | You need associated data in views | Preloads with 1-2 additional queries |
joins | You filter by association columns | Single JOIN query, no preloading |
preload | You want separate queries (no conditions on association) | Always uses separate queries |
eager_load | You need LEFT OUTER JOIN behavior | Single query with JOIN |
After minimizing data loads, apply where clauses to filter at the database level and use limit/offset for pagination.
Which rendering method should you use?
Rails provides three rendering approaches, each with different performance characteristics:
| Rendering Method | Best Use Case | Performance Impact | Maintainability |
|---|---|---|---|
| Inline rendering | Simple, static content | Fastest for basic views | Low for complex logic |
| Partial rendering | Reusable components | Moderate overhead per lookup | High modularity |
| Collection rendering | Lists of similar items | Optimized batch operations | Great for repeated patterns |
Why partials inside loops destroy performance
Each partial render inside a loop triggers a separate template lookup. For 100 items, that is 100 lookups.
<%# Bad: 100 template lookups %>
<% @posts.each do |post| %>
<%= render partial: 'post', locals: { post: post } %>
<% end %>
<%# Good: 1 template lookup, batch rendering %>
<%= render @posts %>The collection rendering version can drop render times from 300ms+ to under 100ms. The larger the dataset, the more dramatic the improvement.
How does caching accelerate views?
Fragment caching
Wrap static or semi-static sections in cache blocks:
<% cache @product do %>
<div class="product-card">
<h3><%= @product.name %></h3>
<p><%= @product.description %></p>
</div>
<% end %>Rails automatically invalidates the cache when the record’s updated_at changes.
Russian doll caching
Nest cache fragments so that updating one record only invalidates its specific cache, not the entire collection:
<% cache ['product-list', @products.maximum(:updated_at)] do %>
<% @products.each do |product| %>
<% cache product do %>
<%= render product %>
<% end %>
<% end %>
<% end %>Views that took 200-300ms can drop to under 50ms with proper caching. The key is identifying which parts stay static versus which change on every request.
Which columns need database indexes?
An index lets the database locate records without scanning every row. Add indexes to:
- Columns used in
WHEREclauses (e.g.,status,category_id) - Columns used in
ORDER BY(e.g.,published_at,created_at) - Foreign keys used in
JOINconditions - Columns used in unique constraints
# Migration example
add_index :products, :category_id
add_index :products, [:category_id, :price] # Composite index
add_index :blog_posts, :published_atComposite indexes are especially powerful. A product listing filtered by category and sorted by price benefits from a single [:category_id, :price] index rather than two separate ones.
How do you monitor view performance?
Without measurement, optimization is guesswork. Use a layered monitoring approach:
- Rails logs: Check render times for each view. Target anything consistently above 100-200ms.
- Bullet gem: Catches N+1 queries during development before they reach production.
- Rack Mini Profiler: Shows detailed timing breakdowns per request, including DB queries and view rendering.
- APM tools (New Relic, Scout, Skylight): Track real-user performance in production, identify slow endpoints, and monitor trends over time.
Establish baseline measurements before making changes. A view rendering in 300ms might seem acceptable until you discover it could render in 80ms with proper eager loading and caching.
Practical Implementation: The USEO Approach
After optimizing Rails views across dozens of production applications, we have developed a systematic process at USEO:
Profile before optimizing. We never guess which views are slow. We instrument every client app with Rack Mini Profiler in development and an APM tool in production. The data consistently shows that 80% of rendering time comes from 20% of views. We fix those first.
The “three-pass” optimization. For each slow view, we apply fixes in order of impact:
- Query layer: Fix N+1s with
includes, add missing indexes, reduce selected columns - Render layer: Replace partial-in-loop with collection rendering, extract expensive computations to presenters
- Cache layer: Add fragment caching for stable sections, Russian doll caching for nested collections
This order matters. Caching a view that runs 47 queries per request just hides the problem. Fix the queries first, then cache.
Presenter objects over helpers. We avoid putting formatting logic in helpers or views. Instead, we use presenter (decorator) objects that wrap models and expose formatted values. This keeps views clean, makes caching more predictable, and lets us test formatting independently.
Cache warming for critical paths. For high-traffic pages, we run a background job after deployments that hits key views to warm caches. Users never see cold-cache render times. This is especially important for landing pages and product listings.
Database-level pagination. We never load full collections. Even with includes, loading 10,000 records to display 25 is wasteful. We use kaminari or pagy for cursor-based or offset pagination, keeping memory usage constant regardless of total record count.
FAQs
How do you detect N+1 query issues in Rails?
Use the Bullet gem in development. It watches every request and alerts you when an N+1 query occurs. For existing apps, enable Rails’ strict_loading mode on specific associations to raise errors when lazy loading happens. In production, APM tools like New Relic flag endpoints with excessive query counts.
When should you use fragment caching vs Russian doll caching?
Fragment caching works for standalone sections that update infrequently, like a navigation menu or sidebar. Russian doll caching is better for nested collections where individual items update independently. For example, a blog index page where each post card is cached separately but the overall list cache depends on the most recent updated_at across all posts.
How much performance improvement can you expect from these techniques?
Results vary, but typical gains we see at USEO: fixing N+1 queries reduces page load by 40-60%, switching from partial-in-loop to collection rendering cuts render time by 50-70%, and adding fragment caching reduces render time by 80-90% for cached views. Combined, a view rendering in 400ms commonly drops to 40-80ms.