Action Cable for real-time updates in Ruby on Rails - Performance & Optimization

Performance: Action Cable for real-time updates

MEDIUM IMPACT

Action Cable impacts the page's interaction responsiveness and network usage by enabling real-time data updates without full page reloads.

Updating UI in real-time with Action Cable

Ruby on Rails

class ChatChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'chat_channel'
  end

  def receive(data)
    # Broadcast only complete messages, not every keystroke
    if data['message'].present?
      ActionCable.server.broadcast('chat_channel', data)
    end
  end
end

# Client-side: sends message only on submit

Reduces network traffic and UI updates by sending fewer, meaningful messages, improving input responsiveness.

📈 Performance GainSingle reflow per message, lower CPU usage, better INP

Updating UI in real-time with Action Cable

Ruby on Rails

class ChatChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'chat_channel'
  end

  def receive(data)
    ActionCable.server.broadcast('chat_channel', data)
  end
end

# Client-side: broadcasts every keystroke as a message

Broadcasting every keystroke floods the network and triggers many UI updates, causing input lag and high CPU usage.

📉 Performance CostTriggers many reflows and repaints per second, increasing INP and CPU load

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Broadcast every keystroke	Many small DOM updates	Multiple reflows per second	High paint cost due to frequent changes	[X] Bad
Broadcast on message submit	Few DOM updates	Single reflow per message	Low paint cost	[OK] Good

Rendering Pipeline

Action Cable receives WebSocket messages, triggers JavaScript updates that modify the DOM, causing style recalculation, layout, paint, and composite steps.

→JavaScript Execution

→Style Calculation

→Layout

→Paint

→Composite

⚠️ BottleneckLayout and Paint stages due to frequent DOM updates from real-time messages

Core Web Vital Affected

INP

Action Cable impacts the page's interaction responsiveness and network usage by enabling real-time data updates without full page reloads.

Optimization Tips

1Avoid broadcasting too many small messages; batch updates when possible.

2Minimize DOM changes triggered by real-time messages to reduce layout thrashing.

3Monitor performance with DevTools to detect excessive layout and paint events.

Performance Quiz - 3 Questions

What is a common performance issue when using Action Cable for real-time updates?

A Caching messages on the client side

B Sending too many small messages causing frequent DOM updates

C Using WebSockets instead of HTTP polling

D Using JSON instead of XML for messages

DevTools: Performance

How to check: Record a session while interacting with the real-time feature. Look for frequent Layout and Paint events triggered by WebSocket messages.

What to look for: High frequency of Layout and Paint events indicates inefficient updates; fewer events mean better performance.

Practice

1. What is the main purpose of Action Cable in a Rails application?

easy

A. To add real-time features allowing live updates without page reloads

B. To manage database migrations automatically

C. To handle background jobs and scheduling

D. To style the application with CSS frameworks

Solution

1. Step 1: Understand Action Cable's role

   Action Cable integrates WebSockets into Rails to enable live, real-time communication.

2. Step 2: Compare options with Action Cable's purpose

   Only To add real-time features allowing live updates without page reloads describes real-time updates without page reloads, which is what Action Cable does.

3. Final Answer:

   To add real-time features allowing live updates without page reloads -> Option A

4. Quick Check:

   Real-time updates = To add real-time features allowing live updates without page reloads [OK]

Hint: Remember: Action Cable = live updates without refreshing [OK]

Common Mistakes:

• Confusing Action Cable with background job tools
• Thinking it manages database tasks
• Assuming it styles the app

2. Which of the following is the correct way to create a channel subscription in a Rails JavaScript client using Action Cable?

easy

A. App.cable.subscriptions.create('ChatChannel')

B. App.cable.subscribe('ChatChannel')

C. App.cable.connect('ChatChannel')

D. App.cable.open('ChatChannel')

Solution

1. Step 1: Recall Action Cable subscription syntax

   The correct method to subscribe to a channel is using subscriptions.create.

2. Step 2: Match options with correct method

   Only App.cable.subscriptions.create('ChatChannel') uses subscriptions.create('ChatChannel'), which is the correct syntax.

3. Final Answer:

   App.cable.subscriptions.create('ChatChannel') -> Option A

4. Quick Check:

   Subscription method = subscriptions.create [OK]

Hint: Use subscriptions.create to subscribe to channels [OK]

Common Mistakes:

• Using subscribe instead of subscriptions.create
• Using connect or open which are invalid methods
• Missing quotes around channel name

3. Given this channel code in Rails:

class ChatChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'chat_room'
  end
end

And this JavaScript subscription:

App.cable.subscriptions.create('ChatChannel', {
  received(data) {
    console.log(data.message)
  }
})

What will happen when the server broadcasts { message: 'Hello!' } to 'chat_room'?

medium

A. Nothing will happen because the channel name is incorrect

B. The message 'Hello!' will be logged in the browser console

C. The message will be displayed as an alert popup

D. The server will throw an error due to missing perform method

Solution

1. Step 1: Understand the channel subscription and streaming

   The channel streams from 'chat_room', and the client subscribes to 'ChatChannel' with a received callback logging data.message.

2. Step 2: Analyze the broadcast effect

   When the server broadcasts { message: 'Hello!' } to 'chat_room', the client receives it and logs 'Hello!' to the console.

3. Final Answer:

   The message 'Hello!' will be logged in the browser console -> Option B

4. Quick Check:

   Broadcast to stream triggers received callback = The message 'Hello!' will be logged in the browser console [OK]

Hint: Broadcast to stream triggers received callback logging message [OK]

Common Mistakes:

• Confusing channel name with stream name
• Expecting alert instead of console log
• Thinking server errors without perform method

4. Identify the error in this Action Cable channel code:

class NotificationsChannel < ApplicationCable::Channel
  def subscribed
    stream_from notifications
  end
end

medium

A. The channel class should inherit from ApplicationController

B. The subscribed method is missing a call to reject unauthorized users

C. The stream_from argument should be a string, not a variable

D. The stream_from method is deprecated and should not be used

Solution

1. Step 1: Check the stream_from argument type

   The argument to stream_from must be a string representing the stream name, e.g., 'notifications'.

2. Step 2: Identify the error in the code

   The code uses notifications without quotes, treating it as a variable, which causes an error.

3. Final Answer:

   The stream_from argument should be a string, not a variable -> Option C

4. Quick Check:

   stream_from needs string argument [OK]

Hint: Always quote stream names in stream_from method [OK]

Common Mistakes:

• Forgetting quotes around stream name
• Inheriting from wrong class
• Assuming stream_from is deprecated

5. You want to broadcast a message to all users subscribed to 'notifications' channel whenever a new comment is created. Which code snippet correctly achieves this in Rails?

hard

A. ActionCable.broadcast('notifications', @comment.body)

B. NotificationsChannel.broadcast_to('notifications', { comment: @comment.body })

C. broadcast_to('notifications', { comment: @comment.body })

D. ActionCable.server.broadcast('notifications', { comment: @comment.body })

Solution

1. Step 1: Identify the correct broadcast method

   To send a message to all subscribers of a stream, use ActionCable.server.broadcast(stream, data).

2. Step 2: Analyze options for correct usage

   ActionCable.server.broadcast('notifications', { comment: @comment.body }) uses ActionCable.server.broadcast with stream name and data hash, which is correct.

3. Final Answer:

   ActionCable.server.broadcast('notifications', { comment: @comment.body }) -> Option D

4. Quick Check:

   Broadcast to stream uses ActionCable.server.broadcast [OK]

Hint: Use ActionCable.server.broadcast to send to all subscribers [OK]

Common Mistakes:

• Using broadcast_to without a model instance
• Calling broadcast on ActionCable directly
• Passing data without wrapping in a hash