𝗧𝗵𝗲 𝟱𝟬𝗺𝘀 𝗥𝘂𝗹𝗲: 𝗛𝗼𝘄 𝗢𝗿𝗱𝗲𝗿 𝗕𝗼𝗼𝗸 𝗕𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝗦𝗮𝘃𝗲𝘀 𝗔𝗚 𝗚𝗿𝗶𝗱 𝗙𝗿𝗼𝗺 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗛𝗲𝗹𝗹

Why do trading dashboards freeze the moment markets get volatile?
I hit this exact wall building a real‑time crypto app with AG Grid — and the fix came down to one simple rule:

👉 𝗕𝗮𝘁𝗰𝗵 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 𝗲𝘃𝗲𝗿𝘆 𝟱𝟬𝗺𝘀.

𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺
A live order book from the Bitfinex WebSocket API v2 can fire dozens of updates per second during volatility.
If you naïvely dispatch every message:
Redux fires constantly
React re-renders constantly
AG Grid tries to reconcile rows constantly
AG Grid is fast — but not “hundreds of DOM updates per second” fast.
The result:
❌ frozen UI
❌ dropped frames
❌ a dashboard that feels like a slideshow

𝗧𝗵𝗲 𝟱𝟬𝗺𝘀 𝗥𝘂𝗹𝗲
Instead of dispatching every update, we buffer them and flush once every 50ms.
That’s ~20 updates per second.
Smooth. Stable. Still “real‑time” to the human eye.
ts
let buffer: BookUpdate[] = []

setInterval(() => {
if (buffer.length === 0) return
dispatch(bookBatchUpdateReducer(buffer))
buffer = []
}, 50)

AG Grid now processes one batch per cycle, not fifty individual transactions.
FPS stays high. The UI stays responsive.

𝗪𝗵𝘆 𝟱𝟬𝗺𝘀?
Human perception of “instant” is ~100ms.
At 50ms:
Feels real‑time
Cuts render load by an order of magnitude
Avoids thrashing the grid
Go lower (10ms) → you’re back to choking the main thread.
Go higher (200ms) → the order book feels sluggish.

𝟱𝟬𝗺𝘀 𝗶𝘀 𝘁𝗵𝗲 𝘀𝘄𝗲𝗲𝘁 𝘀𝗽𝗼𝘁.

𝗧𝗵𝗲 𝗕𝗿𝗼𝗮𝗱𝗲𝗿 𝗟𝗲𝘀𝘀𝗼𝗻
High‑frequency data doesn’t care about your render budget.

𝗬𝗼𝘂 𝗵𝗮𝘃𝗲 𝘁𝗼 𝗲𝗻𝗳𝗼𝗿𝗰𝗲 𝗼𝗻𝗲.
Batching applies to:
live sports feeds
IoT telemetry
logistics tracking
any system where data outpaces UI capacity
AG Grid is powerful, but it still lives on the main thread. Respect that, and your UI will thank you.

Building this in my React 19 + Redux Toolkit crypto project taught me more about browser performance than any tutorial ever could.

What batching strategies have you used in high‑frequency UIs?

Would love to hear your experiences.

𝗪𝗿𝗶𝘁𝘁𝗲𝗻 𝗯𝘆 𝗥𝗶𝗰𝗮𝗿𝗱𝗼 𝗦𝗮𝘂𝗺𝗲𝘁𝗵
𝗦𝗲𝗻𝗶𝗼𝗿 𝗙𝗿𝗼𝗻𝘁‑𝗘𝗻𝗱 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 | 𝗥𝗲𝗮𝗹‑𝗧𝗶𝗺𝗲 𝗨𝗜 𝗦𝗽𝗲𝗰𝗶𝗮𝗹𝗶𝘀𝘁