.png){kind=logo}
Enterprise teams build AI interfaces, show smooth demos, and watch them break in production. Connecting raw token streams to React components causes slow renders, lag, and broken state. All this originates in the frontend, not the model.
AI chat operates differently from standard interfaces. Responses arrive as continuous event streams while users cancel requests, switch chats, or trigger tools simultaneously.
Separate stream processing from UI rendering. Store incoming events in a state container outside your React component tree. Let your UI read from state at a controlled rate. This architectural shift grants you total control over rendering speeds, user cancellations, and session management.
A common implementation, whether built by hand or with a hook like Vercel’s useChat, reads a POST response stream inside a React component rather than relying on the reconnect and resume behavior provided by the browser’s GET-based EventSource API [1]. The AI SDK notes that each received chunk triggers a render [4].
The problem is that chunks arrive one after another. React batches updates within a single task, but not across separate tasks [2]. As a result, each chunk can trigger another render. The frontend then has to process the updated message and, in a typical transcript, render the messages already on screen again.
After, the cost grows as the response gets longer and as the conversation continues. All of this happens on the same thread responsible for handling user input, while the model can produce tens or hundreds of tokens per second [7]. People read at a much slower pace, at around four words per second [6].
The same setup also leaves the component responsible for three things it should not have to control: scheduling (when the UI updates), concurrency control (which stream may write), and protocol interpretation (what the bytes mean). All of these are not responsibilities of the UI component itself.
Interaction latency that scales with session length. As the transcript grows, each update takes more work to render. Once a task takes more than 50 ms, it can start blocking user input [3]. When this delay pushes the interface beyond the 200 ms threshold associated with a good Interaction to Next Paint [3], typing in the composer starts to feel slow. Because the problem appears gradually as conversations get longer, teams often blame the model instead.
Concurrency races on stop, regenerate, and switch. The current response often lives in effect closures and isLoading booleans, leaving no central mechanism to decide which stream is allowed to update state. Switch conversations while a response is still streaming, and late events can update the wrong conversation. Open WebUI documents this failure mode: “Chat B’s content disappears — replaced by a loading state meant for Chat A” [8]. Every new entry point, such as edit, retry, or branch, adds another possible interleaving that a single boolean cannot represent.
Protocol flattening. AI providers do not send plain text. They send typed event streams. Anthropic’s protocol, for example, interleaves text, thinking, and tool-call deltas, with tool arguments arriving as partial JSON. It also includes ping and mid-stream error events, with strict ordering within each block [5]. Flattening these events into string concatenation loses information about what each event means. The client might try to parse incomplete tool arguments, miss an error in the middle of the stream, or store truncated output as final content. That corrupted state then becomes part of the context sent with the next turn.
The correction: ingest, log, project
The correction introduces one boundary with three components, none of which imports React.
The stream ingestor handles the connection and provider events. It turns them into typed application events, checks their order, and gives each response a run ID. Starting, stopping, regenerating, or switching a conversation creates a new ID. Late events from an old run are dropped before they reach the conversation state. AbortController also lives here, keeping cancellation separate from the React component lifecycle.
The conversation log is the single source of truth. It records events in order and marks a “response complete” only when the provider sends its final message event, such as message_stop. A dropped connection therefore cannot look like a completed answer. The recorded stream also becomes a test case and debugging trace.
The projection scheduler turns the log into the state React needs to display. Using useSyncExternalStore, it updates the UI on a controlled schedule instead of on every token. Updates can be batched to the browser’s frame budget or a roughly 50 ms interval. Per-message views stay referentially stable, so memoized components can skip unchanged work.
provider SSE / fetch stream
│ typed protocol events
▼
┌─ Conversation runtime (no React dependency) ──────┐
│ STREAM INGESTOR │
│ parse · validate ordering · epoch-guard writes │
│ owns AbortController │
│ │ append │
│ ▼ │
│ CONVERSATION LOG (append-only, replayable) │
│ terminal-event commits · compaction │
│ taps: persistence · tracing · tests │
│ │ derive │
│ ▼ │
│ PROJECTION SCHEDULER │
│ frame-budget flush · a11y granularity │
│ referentially stable views │
└────────────┬──────────────────────────────────────┘
│ useSyncExternalStore commit
▼
React component tree
Figure 1. The conversation runtime boundary: ingest → log → project.
The trade-offs are real: the UI trails the stream by one flush interval, and the architecture requires more code than a simple hook. For short prototype sessions without tool calls, it is probably unnecessary. The event log also needs periodic compaction.
Update throttling in newer hooks reduces rendering pressure [4], but leaves stream ownership, concurrency, and protocol handling inside the component.
The payoff is that interaction cost stops growing with conversation length.
I benchmarked three versions of the same React chat harness, changing only the architectural couplings described above. Each streamed a 1,500-token Markdown response into a 48-message transcript while real user interactions were running.
The difference between a demo and production appears quickly. In the same benchmark, the naive architecture recorded a p95 heartbeat-task lateness of 20.9 ms at 12 messages, based on the median of three runs. As the conversation grew to 48 messages, the gap between architectures became more pronounced, which is the configuration shown in the table. The 12-message result is useful here as a reminder of why a seemingly acceptable architecture can still make its way into production: at demo-scale workloads, its performance may look perfectly reasonable.
Table 1. Setup: React 18.3.1 (profiling build), marked 12, headless Chromium 141 via Playwright, 2-vCPU Linux container; 1,500 word-tokens at 100/s into a 48-message (~6,700-token) transcript; medians of 3 runs. Commit counts and React main-thread share from React.Profiler; frame rate via rAF; click→next-paint from PerformanceObserver (event timing); queued-task delay = lateness of a 100 ms heartbeat task — a proxy for how long any input-triggered task waits to run. Ratios transfer across hardware; absolute values will not.
At 48 messages, each UI update takes three times longer in the naive version. Frame rate drops, and a user interaction waits 61 ms before its handler runs.
The naive version attempts 100 UI updates per second but manages only 38. The main thread becomes saturated, so updates start to pile up and get merged. Backpressure appears where it hurts most: in the UI. The projection variant commits 5× less often than the per-chunk, memoized one and spends 12× less main-thread time than the naive one, at identical perceived text speed.
The engineering conclusion is to concentrate on treating an LLM conversation as distributed-systems data: an ordered, typed, cancellable event log rather than to optimize the chat component. The frontend should control when the UI updates.
Teams building AI applications should also review streaming state architecture like an API contract. Who controls the update schedule? Who decides which stream can write? Which events mark a response as complete?
Measure interactivity at realistic conversation lengths, not demo lengths. A chat interface that feels responsive at message ten should not degrade by message fifty.
WHATWG. HTML Living Standard, §9.2 Server-sent events. https://html.spec.whatwg.org/multipage/server-sent-events.html
React Team. React v18.0 — automatic batching. https://react.dev/blog/2022/03/29/react-v18
Google web.dev. Interaction to Next Paint (INP); Optimize long tasks. https://web.dev/articles/inp; https://web.dev/articles/optimize-long-tasks
Vercel. AI SDK UI: Chatbot — per-chunk renders and the throttle option. https://ai-sdk.dev/docs/ai-sdk-ui/chatbot
Anthropic. Streaming Messages — event types and ordering. https://platform.claude.com/docs/en/build-with-claude/streaming
Brysbaert, M. (2019). How many words do we read per minute? A review and meta-analysis of reading rate. Journal of Memory and Language, 109. https://doi.org/10.1016/j.jml.2019.104047
Artificial Analysis. LLM output speed comparisons. https://artificialanalysis.ai/models
Open WebUI. Discussion #21462: chat switching causes race conditions — loading state leaks between chats. https://github.com/open-webui/open-webui/discussions/21462
