Sending emails from controllers in Ruby on Rails - Performance & Optimization

Performance: Sending emails from controllers

MEDIUM IMPACT

This affects server response time and user experience by potentially delaying page load while the email is sent.

Sending an email immediately after a user action in a controller

Ruby on Rails

def create
  UserMailer.welcome_email(@user).deliver_later
  redirect_to root_path
end

Using background jobs to send emails asynchronously frees the controller to respond immediately.

📈 Performance GainNon-blocking response, improves INP by reducing server response delay

Sending an email immediately after a user action in a controller

Ruby on Rails

def create
  UserMailer.welcome_email(@user).deliver_now
  redirect_to root_path
end

Sending email synchronously blocks the controller action until the email is sent, increasing response time.

📉 Performance CostBlocks rendering for 200-500ms or more depending on email server latency

Performance Comparison

Pattern	Server Response Time	User Wait	Impact on INP	Verdict
Synchronous email sending (deliver_now)	Increases by 200-500ms+	User waits longer for page load	High negative impact	[X] Bad
Asynchronous email sending (deliver_later)	Minimal increase, handled in background	User sees page immediately	No impact	[OK] Good

Rendering Pipeline

When emails are sent synchronously in controllers, the server holds the response until the email operation completes, delaying the HTML response and blocking the browser from rendering the page.

→Server Response

→Network Transfer

→Browser Rendering

⚠️ BottleneckServer Response time due to synchronous email sending

Core Web Vital Affected

INP

This affects server response time and user experience by potentially delaying page load while the email is sent.

Optimization Tips

1Never send emails synchronously in controller actions to avoid blocking response.

2Use deliver_later with background job processors to send emails asynchronously.

3Monitor server response times to detect blocking operations like synchronous email sending.

Performance Quiz - 3 Questions

What is the main performance problem with sending emails synchronously in a Rails controller?

A It causes layout shifts on the page.

B It increases CSS rendering time in the browser.

C It blocks the server response, delaying page load.

D It reduces JavaScript execution speed.

DevTools: Network and Performance panels

How to check: Record a performance profile while triggering the email sending action; check server response time and look for delays before first byte.

What to look for: Long server response time before HTML starts loading indicates synchronous email sending blocking the response.

Practice

1. What is the main role of a controller when sending emails in Rails?

easy

A. To call the mailer method and trigger the email sending

B. To write the email content and layout

C. To configure the SMTP settings

D. To store email templates in the database

Solution

1. Step 1: Understand controller responsibility

   Controllers handle user requests and trigger actions like sending emails by calling mailer methods.

2. Step 2: Identify mailer role

   Mailers contain email content and setup, not controllers.

3. Final Answer:

   To call the mailer method and trigger the email sending -> Option A

4. Quick Check:

   Controllers trigger mailers [OK]

Hint: Controllers trigger mailers, mailers build emails [OK]

Common Mistakes:

• Writing email content in controllers
• Configuring SMTP in controllers
• Storing templates in controllers

2. Which of the following is the correct syntax to send an email immediately from a controller using a mailer named UserMailer and a method welcome_email?

easy

A. UserMailer.welcome_email.deliver_later(params[:user])

B. UserMailer.welcome_email(params[:user]).deliver_now

C. UserMailer.deliver_now.welcome_email(params[:user])

D. UserMailer.welcome_email(params[:user]).send_now

Solution

1. Step 1: Identify mailer method call

   The mailer method is called with parameters: UserMailer.welcome_email(params[:user]).

2. Step 2: Use correct delivery method

   To send immediately, use deliver_now after the mailer method call.

3. Final Answer:

   UserMailer.welcome_email(params[:user]).deliver_now -> Option B

4. Quick Check:

   Immediate send = deliver_now after mailer call [OK]

Hint: Call mailer method then add .deliver_now for immediate send [OK]

Common Mistakes:

• Using deliver_later for immediate send
• Calling deliver_now before mailer method
• Using non-existent send_now method

3. Given this controller code snippet:

def create
  @user = User.new(user_params)
  if @user.save
    UserMailer.welcome_email(@user).deliver_later
    redirect_to root_path, notice: 'User created!'

What happens when this code runs successfully?

medium

A. The welcome email is sent immediately before redirecting

B. The redirect happens only after the email is sent

C. The welcome email is queued to be sent later, then redirect happens

D. The email is never sent because deliver_later is incorrect here

Solution

1. Step 1: Understand deliver_later behavior

   Calling deliver_later queues the email to be sent asynchronously in the background.

2. Step 2: Analyze controller flow

   The redirect happens immediately after queuing the email, not waiting for sending.

3. Final Answer:

   The welcome email is queued to be sent later, then redirect happens -> Option C

4. Quick Check:

   deliver_later queues email, redirect immediate [OK]

Hint: deliver_later queues email, does not block controller [OK]

Common Mistakes:

• Thinking deliver_later sends email immediately
• Assuming redirect waits for email sending
• Believing deliver_later is invalid syntax

4. Identify the error in this controller code snippet:

def notify
  UserMailer.notify_user.deliver_now(user)
  redirect_to dashboard_path
end

medium

A. deliver_now is not a valid method for sending emails

B. redirect_to should be called before sending email

C. notify_user method cannot be called without parentheses

D. deliver_now should be called after passing user argument to notify_user

Solution

1. Step 1: Check method call order

   The user argument must be passed to notify_user before calling deliver_now.

2. Step 2: Correct syntax

   Correct call: UserMailer.notify_user(user).deliver_now.

3. Final Answer:

   deliver_now should be called after passing user argument to notify_user -> Option D

4. Quick Check:

   Pass args before deliver_now [OK]

Hint: Pass arguments inside mailer method, then call deliver_now [OK]

Common Mistakes:

• Calling deliver_now with arguments
• Calling redirect_to before email
• Misusing parentheses in method calls

5. You want to send a confirmation email from a controller only if the user has a verified email address. Which is the best way to implement this?

hard

A. In the controller, check if user.verified? then call UserMailer.confirmation_email(user).deliver_now

B. Always call UserMailer.confirmation_email(user).deliver_now and check verification inside the mailer

C. Send the email unconditionally and add a condition in the email template

D. Call UserMailer.confirmation_email.deliver_now(user) without any condition

Solution

1. Step 1: Decide where to check condition

   Controller should decide if email should be sent based on user verification status.

2. Step 2: Call mailer only when condition is true

   Call UserMailer.confirmation_email(user).deliver_now only if user.verified? is true.

3. Final Answer:

   In the controller, check if user.verified? then call UserMailer.confirmation_email(user).deliver_now -> Option A

4. Quick Check:

   Check condition in controller before sending email [OK]

Hint: Check conditions in controller before calling mailer [OK]

Common Mistakes:

• Checking conditions inside mailer or template
• Sending emails unconditionally
• Passing arguments after deliver_now