How to Fix LLM Streaming Lag and React Render Storms

The LLM 'Render Storm': Why 50 Tokens/Sec Will Lag Your React App

Generative AI is transforming how we build applications, but it has introduced a silent performance killer in frontend development: the "Render Storm." If you are building an AI-powered chat interface or a real-time document generator, you have likely encountered the challenge of streaming text.

Many developers start by piping their LLM stream directly into a React state variable. It seems logical—data comes in, you update the state, and the UI reflects the change. However, this approach is a recipe for disaster. If you aren't careful, your high-performance LLM implementation will quickly become a high-performance lag machine.

The Math Behind the Lag

To understand why this happens, we have to look at the numbers. Modern LLMs can stream tokens at speeds ranging from 30 to over 100 tokens per second.

If you are using a naive implementation where every incoming network chunk triggers a setState call, you are effectively forcing React to perform a full render cycle for every single token. At 50 tokens per second, that is 50 state updates per second.

Because these tokens arrive as asynchronous network chunks, React’s automatic batching—which usually coalesces updates within the same synchronous event loop task—cannot help you. Each token arrives as its own discrete task, forcing a re-render.

The Frame Budget Reality

To maintain a smooth 60 frames per second (FPS) experience, your application must complete its render and commit cycle within a 16.6ms frame budget. When you trigger 50 renders per second, you are consuming your entire frame budget just on reconciliation and DOM updates. The result is predictable:

• Severe scroll jitter
• Input latency
• Dropped frames
• A UI that feels "locked" or unresponsive

In a recent benchmark I conducted on a production React 18.3 build, streaming at 80 tokens per second resulted in over 40 renders per second, with average commit durations hitting 52ms. The interface was essentially unusable.

The Solution: Decouple Intake from Render

The key to solving this is to decouple your stream intake from your render cycle. You should not be letting the network dictate your frame rate. Instead, you should control the flow of updates to the UI.

The requestAnimationFrame Pattern

The most effective approach for 95% of use cases is to buffer incoming tokens in a mutable useRef and flush them to the state using requestAnimationFrame. This ensures that your UI updates only as often as the browser can actually paint them.

import { useState, useRef, useCallback } from 'react';

const useBufferedStream = () => {
  const [content, setContent] = useState('');
  const streamRef = useRef('');
  const requested = useRef(false);

  const handleToken = useCallback((token) => {
    streamRef.current += token;

    if (!requested.current) {
      requested.current = true;
      requestAnimationFrame(() => {
        setContent(streamRef.current);
        requested.current = false;
      });
    }
  }, []);

  return { content, handleToken };
};

By implementing this pattern, we effectively cap the render rate at 12–16 frames per second, which is perfectly aligned with the display refresh rate. In my tests, this simple change caused the average commit duration to plummet from 52ms to just 5ms. The UI became buttery smooth, even during heavy generation tasks.

When You Need More: Web Workers and Canvas

For most applications, the requestAnimationFrame buffer is sufficient. However, if you are building an application with extreme throughput requirements—say, exceeding 150 tokens per second or rendering massive amounts of markdown—you may need to offload the heavy lifting.

In these scenarios, consider:

1. Web Workers: Move the text processing, parsing, and measurement logic to a background thread to keep the main thread free for interaction.
2. Canvas Rendering: If the text volume is massive, avoid the DOM entirely. Drawing text directly to a <canvas> element bypasses the overhead of the React reconciliation tree, allowing for near-instantaneous updates regardless of token speed.

Final Thoughts

Don't let your AI features compromise your user experience. While it is tempting to use the simplest implementation, streaming data requires a more disciplined approach to React state management. By buffering your stream, you can ensure your application remains fast, responsive, and professional.

Are you still relying on raw setState for your streaming AI features, or have you implemented a custom buffering solution? Let me know in the comments.",article_title: