How I Kept a Live Chat Feed Smooth at 3,700+ Messages

shrutictc2 — Sat, 11 Jul 2026 00:30:15 +0000

I built LiveShop, a mini live-shopping stream UI, to answer a question I kept running into as a frontend-curious grad: tutorials teach you how to render a list, but they never teach you what happens when that list gets hit with the kind of traffic a real live stream produces. So I built something that would force the problem to show up, then fixed it, then measured whether the fix actually worked.

The setup

LiveShop simulates a live-shopping broadcast - the kind of interface a small merchant might use to sell products while streaming. A mock event engine fires chat messages, reactions, and purchase notifications on an interval, standing in for what a real WebSocket connection to a streaming backend would deliver. On top of that sits a chat feed, a scrollable product carousel, and a floating reaction animation layer.

None of that is unusual. The interesting part started once I asked: what happens when message volume spikes?

Where it breaks

A naive chat feed is just messages.map(m => <ChatRow key={m.id} {...m} />). It's the first thing anyone reaches for, and it's fine — right up until it isn't. At 50 messages, nothing looks wrong. At a few hundred, every new message triggers a full re-render pass across every row in the DOM, including the hundreds that have already scrolled out of view and that nobody can see. The browser is doing layout and paint work for pixels that aren't on screen.

In a real live stream, this is exactly the wrong failure mode, because message volume doesn't arrive evenly. It spikes — right after a product drop, right when something funny happens on stream, right when a popular creator says something quotable. That's precisely the moment a chat feed can't afford to stutter, and precisely the moment a naive implementation is most likely to.

What I measured

Rather than guess whether this mattered, I built a way to test it directly. LiveShop has a "Simulate spike" button that fires 500 messages instantly, plus a live FPS readout using requestAnimationFrame to track real frame timing — not a theoretical estimate, an actual rolling average of how long frames were taking on my machine as the spike happened.

With a plain .map() render, pushing the feed to roughly 3,700 accumulated messages dropped frame rate to 25fps, with visible stutter. A quick console check — document.querySelectorAll('.chat-row').length — confirmed why: 3,333 DOM nodes, one for every message that had ever arrived, all still mounted and being diffed on every update.

The fix

I virtualized the list with react-window. Instead of mounting a DOM node per message, it only renders the rows that are actually inside the visible scroll viewport — roughly 12–15 at a time — and recycles them as the user scrolls. The feed can hold 50 messages or 50,000; the DOM footprint stays constant either way.

After switching over, the same spike test — thousands of messages, fired as fast as the mock stream could generate them — held a steady 60fps, and the DOM node count settled at 14, regardless of how high the message count climbed.

The FPS number is the visible symptom. The DOM node count is the actual mechanism, and it's the more interesting one, because it holds true even before performance visibly degrades — it's not something you'd necessarily notice by eye until the spike hits, but it's there from message one.

A few other load-bearing decisions

Virtualization solved the big one, but a few smaller choices mattered too:

Reaction animations are capped at 8 concurrent bubbles. Reactions can arrive multiple times a second in a busy stream, and animating every single one would spawn DOM nodes faster than the browser could clean them up. Capping the count doesn't lose meaningful reactions — they arrive faster than a human can register each one individually anyway.
Chat history is capped at 5,000 messages client-side. A long-running stream shouldn't grow memory without bound, so old messages page out once the cap is hit — the same pattern a production client would need.
The mock event stream sits behind a single callback interface. startLiveEventStream(onEvent) is the entire contract. Every component downstream — chat, reactions, viewer count — only depends on that event shape, not on how the events arrive. Swapping the setInterval mock for a real WebSocket connection later would mean changing exactly one file.

What I'd do differently with more time

The FPS readout is honest but manual — I watched the number and wrote down what I saw. A more rigorous version would script the spike test and assert against a performance trace automatically, the way you'd want a real regression test to work rather than something a developer eyeballs once and trusts forever. That's the next thing I'd build if I kept going.

LiveShop is open source on GitHub — the README has the full before/after numbers and architecture notes if you want to dig deeper.