Garbage collection jitter: How to fix high-frequency UI lag

Last month, I spent three days chasing a stutter in a high-frequency trading dashboard. Every time the WebSocket pushed a burst of price updates, the UI would hang for about 180ms, effectively killing the user experience during market volatility.

After digging through Chrome’s Performance profiler, I didn't find a massive memory leak. Instead, I found a constant, rhythmic saw-tooth pattern in the memory graph. My application was triggering garbage collection every few seconds because we were generating thousands of small, short-lived objects per second. The browser's engine was working overtime just to clean up our mess.

Understanding the cost of GC Jitter

When your application allocates memory faster than the browser can reclaim it, the garbage collector eventually forces a "stop-the-world" event. In a UI thread, this manifests as garbage collection jitter. It’s the silent killer of web performance, especially in interfaces that require 60fps responsiveness.

I initially tried to solve this by debouncing the incoming WebSocket messages. It helped, but it also made the UI feel sluggish and stale. We needed the data fast, but we needed to stop the constant object creation.

First attempts and wrong turns

My first instinct was to move the data processing to a Web Worker, which is a standard tactic for preventing main-thread congestion. While that offloaded the heavy lifting, the bottleneck shifted to the serialization cost of moving large JSON objects back and forth over postMessage.

We were still creating the same number of objects; we were just moving where the GC had to clean them up. I realized that if I wanted to eliminate the jitter, I had to stop allocating memory in the hot path altogether.

Implementing Predictive Memory Management

The breakthrough came when I switched to an object pooling strategy. Instead of creating a new object for every price update, I pre-allocated a buffer of objects and reused them.

JAVASCRIPT
// A simple object pool for price updates
const pool = Array.from({ length: 100 }, () => ({ price: 0, symbol: CE9178">'' }));
let pointer = 0;

function updatePrice(symbol, price) {
  const obj = pool[pointer];
  obj.symbol = symbol;
  obj.price = price;
  
  pointer = (pointer + 1) % pool.length;
  return obj;
}

This pattern is a foundational technique for JavaScript optimization through predictive memory management. By keeping the object references stable, I reduced the allocation rate from ~50MB/s to almost zero. The saw-tooth pattern in the memory profiler flattened out, and the main-thread interaction latency dropped to consistently under 16ms.

Comparing Memory Management Strategies

When you're dealing with high-frequency data, you have to choose your trade-offs carefully.

If you’re struggling with memory leaks in your SPAs, you might also want to look into how WeakRef and FinalizationRegistry can help you monitor objects without preventing their collection. However, for high-frequency interaction, pooling is almost always the more effective path to reducing interaction latency.

Avoiding common traps

One caveat: object pooling isn't a silver bullet. You have to be extremely careful with object lifecycles. If you hold onto a reference to a pooled object after the pool has rotated it, you'll see "ghost" data updates that are incredibly difficult to debug.

I also had to ensure that our main-thread optimization efforts didn't inadvertently introduce new leaks. I used FinalizationRegistry to log when objects were being held too long, which helped me identify a few places where I'd accidentally stored a reference in a closure.

FAQ

Q: Does object pooling break React’s immutability? A: Yes, it can. If you're using React, you'll need to clone the pooled object before passing it to state, or use a pattern that treats the pooled object as a transient container.

Q: When should I start worrying about GC jitter? A: If your Performance profiler shows long "Scripting" or "Garbage Collection" tasks occurring during user interactions, it's time to act.

Q: Is this premature optimization? A: If your app is snappy, don't do it. This is a fix for when you've already measured and confirmed that GC is the bottleneck.

Final thoughts

I'm still not entirely convinced that object pooling is the "cleanest" way to write JavaScript, but in the world of high-frequency UIs, it's a necessary evil. I’d love to see a future where engines handle high-churn objects better, but for now, managing the heap manually is the only way to guarantee a consistent frame rate.

If you are just starting to optimize your app, focus on memory management for Core Web Vitals first. Fix the obvious leaks before you dive into the complexities of predictive memory management.