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.

Practice

1. What is the main purpose of a before_action filter in a Rails controller?

easy

A. To run code before a controller action executes

B. To run code after a controller action executes

C. To skip a controller action entirely

D. To define a new controller action

Solution

1. Step 1: Understand the role of filters

   Filters in Rails run code around controller actions to modify behavior.

2. Step 2: Identify the timing of before_action

   before_action runs code before the main action method executes.

3. Final Answer:

   To run code before a controller action executes -> Option A

4. Quick Check:

   before_action = runs before action [OK]

Hint: Before filters run code before actions start [OK]

Common Mistakes:

• Confusing before_action with after_action
• Thinking before_action skips actions
• Assuming before_action defines new actions

2. Which of the following is the correct syntax to define an after filter named log_action in a Rails controller?

easy

A. after_filter :log_action

B. after :log_action

C. before_action :log_action

D. after_action :log_action

Solution

1. Step 1: Recall the modern syntax for after filters

   Rails uses after_action to define code that runs after controller actions.

2. Step 2: Check each option

   after_filter :log_action uses deprecated after_filter. after_action :log_action uses correct after_action. before_action :log_action is for before filters. after :log_action is invalid syntax.

3. Final Answer:

   after_action :log_action -> Option D

4. Quick Check:

   Use after_action for after filters [OK]

Hint: Use after_action, not after_filter, for after filters [OK]

Common Mistakes:

• Using deprecated after_filter instead of after_action
• Mixing before_action with after filters
• Incorrect syntax like 'after :method'

3. Given this controller code:

class PostsController < ApplicationController
  before_action :set_post
  after_action :log_post

  def show
    render plain: @post.title
  end

  private
  def set_post
    @post = Post.find(params[:id])
  end

  def log_post
    Rails.logger.info "Post viewed: #{@post.id}"
  end
end

What will be the output when GET /posts/5 is called, assuming the post with ID 5 has title "Hello"?

medium

A. The page shows "Hello" and logs "Post viewed: 5" after rendering

B. The page shows "Hello" but does not log anything

C. The page shows nothing and logs "Post viewed: 5"

D. An error occurs because @post is not set

Solution

1. Step 1: Understand filter order and effects

   before_action :set_post runs before show, setting @post. after_action :log_post runs after show completes.

2. Step 2: Trace the request flow

   When show runs, @post is set, so render plain: @post.title outputs "Hello". After rendering, log_post logs "Post viewed: 5".

3. Final Answer:

   The page shows "Hello" and logs "Post viewed: 5" after rendering -> Option A

4. Quick Check:

   before_action sets data, after_action logs after render [OK]

Hint: before_action sets data, after_action runs after response [OK]

Common Mistakes:

• Thinking after_action runs before rendering
• Assuming @post is nil in show
• Confusing logging output with page content

4. Identify the error in this controller code:

class UsersController < ApplicationController
  before_action :authenticate_user
  after_action :clear_session

  def index
    # list users
  end

  private
  def authenticate_user
    redirect_to login_path unless current_user
  end

  def clear_session
    session[:temp] = nil
  end
end

medium

A. The methods authenticate_user and clear_session must be public

B. The before_action should be after_action for authentication

C. The after_action runs even if redirect happens, causing errors

D. There is no error; the code works as expected

Solution

1. Step 1: Analyze filter behavior with redirects

   If authenticate_user redirects, the action does not run, but after_action still runs.

2. Step 2: Understand consequences of after_action after redirect

   Running clear_session after redirect can cause unexpected side effects or errors.

3. Final Answer:

   The after_action runs even if redirect happens, causing errors -> Option C

4. Quick Check:

   after_action runs even after redirect [OK]

Hint: after_action runs even if before_action redirects [OK]

Common Mistakes:

• Assuming after_action skips on redirect
• Thinking authentication should be after_action
• Believing private methods must be public

5. You want to run a before_action filter named check_admin only before the edit and update actions in a Rails controller. Which is the correct way to write this?

hard

A. before_action :check_admin, except: [:edit, :update]

B. before_action :check_admin, only: [:edit, :update]

C. after_action :check_admin, only: [:edit, :update]

D. before_filter :check_admin, only: [:edit, :update]

Solution

1. Step 1: Identify correct filter type and options

   Use before_action to run code before actions. Use only: to limit to specific actions.

2. Step 2: Evaluate each option

   before_action :check_admin, only: [:edit, :update] correctly uses before_action with only: [:edit, :update]. before_action :check_admin, except: [:edit, :update] uses except, which excludes those actions. after_action :check_admin, only: [:edit, :update] uses after_action, wrong timing. before_filter :check_admin, only: [:edit, :update] uses deprecated before_filter.

3. Final Answer:

   before_action :check_admin, only: [:edit, :update] -> Option B

4. Quick Check:

   Use before_action with only: for specific actions [OK]

Hint: Use before_action with only: to target specific actions [OK]

Common Mistakes:

• Using except instead of only
• Using after_action instead of before_action
• Using deprecated before_filter