Before and after filters in Ruby on Rails - Performance & Optimization

Performance: Before and after filters

MEDIUM IMPACT

This affects server response time and perceived page load speed by adding processing steps before or after controller actions.

Running code before or after every controller action

Ruby on Rails

class PostsController < ApplicationController
  before_action :load_user, only: [:index, :show, :edit, :update, :destroy]
  before_action :check_permissions, only: [:edit, :update, :destroy]
  after_action :log_request, only: [:create, :update, :destroy]

  def index
    @posts = Post.all
  end

  private

  def load_user
    @user = User.find(session[:user_id])
  end

  def check_permissions
    redirect_to root_path unless @user.admin?
  end

  def log_request
    RequestLogger.log(request)
  end
end

Filters run only on needed actions, reducing unnecessary database calls and processing.

📈 Performance GainReduces server processing time by skipping filters on irrelevant actions, improving response time by 30-70ms.

Running code before or after every controller action

Ruby on Rails

class PostsController < ApplicationController
  before_action :load_user
  before_action :check_permissions
  before_action :log_request

  def index
    @posts = Post.all
  end

  private

  def load_user
    @user = User.find(session[:user_id])
  end

  def check_permissions
    redirect_to root_path unless @user.admin?
  end

  def log_request
    RequestLogger.log(request)
  end
end

All filters run on every action, even if not needed, causing unnecessary database queries and processing.

📉 Performance CostAdds multiple database queries and processing steps per request, increasing server response time by 50-100ms depending on complexity.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Filters run on all actions	N/A (server-side)	N/A	N/A	[X] Bad
Filters limited to needed actions	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Before and after filters run on the server before the HTML is sent to the browser, affecting how fast the page content is generated and delivered.

→Server Processing

→Response Generation

⚠️ BottleneckServer Processing time increases with unnecessary filters.

Core Web Vital Affected

LCP

This affects server response time and perceived page load speed by adding processing steps before or after controller actions.

Optimization Tips

1Only run before and after filters on actions that need them.

2Avoid heavy database queries or processing inside filters.

3Monitor server response times to catch slow filters early.

Performance Quiz - 3 Questions

What is the main performance impact of running before filters on every controller action?

A Causes browser to reflow the page multiple times

B Blocks JavaScript execution on the client

C Increases server response time by running unnecessary code

D Increases CSS paint cost

DevTools: Network

How to check: Open DevTools, go to Network tab, reload the page, and check the server response time in the Timing section.

What to look for: Look for longer server response times indicating slow backend processing due to filters.