How Node.js Cut Memory Usage in Half With One Change

Matteo Collina, a core Node.js contributor, published benchmarks last week showing a 50% reduction in memory usage for Node applications. The mechanism—pointer compression—isn't new. Chrome has used it since 2020. But Node couldn't enable it by default until now, for reasons that illuminate how much invisible engineering shapes the tools we use daily.

The technical change is deceptively simple: V8, the C++ engine powering JavaScript, stores memory addresses as 32-bit offsets instead of full 64-bit pointers. Each pointer shrinks from eight bytes to four. For applications with thousands of objects, arrays, and closures, the savings compound quickly.

The cost? A single addition or subtraction operation every time V8 accesses the heap. "This extra operation is akin to a level one cache hit in terms of computational effort," the benchmarks note. Fast enough to be nearly invisible.

But if the feature existed for years and the overhead was minimal, why didn't Node enable it?

The 4GB Cage Problem

Pointer compression works by storing memory addresses as offsets from a fixed base point. You can fit 4GB of addresses in 32 bits if you know where to start counting. The problem was architectural: V8's implementation forced every isolate—every separate JavaScript execution context—to share the same 4GB memory cage.

For Chrome, where each tab runs in its own process, this worked fine. Each process got its own cage. But Node runs worker threads in a single process. Every worker had to fit in the same 4GB space.

"Enabling pointer compression required the entire node process to share a single 4 gig memory space between the main thread and all the worker threads," the video explanation notes. "This is a significant issue."

Cloudflare had reasons to care about this. Their Workers platform runs thousands of V8 isolates on shared infrastructure. The memory cage limitation directly affected their cost structure. In November 2024, James Snell at Cloudflare initiated work on isolate groups—a V8 feature that would give each worker its own 4GB cage.

Cloudflare also sponsored engineers at Igalia to implement the changes. The pull request merged in October 2025: 62 lines across eight files. Nearly a year for 62 lines.

What 62 Lines Actually Means

That timeline matters. This wasn't bureaucratic delay—it was the reality of changing foundational infrastructure used by millions of applications. Every line had to work correctly across architectures, operating systems, and use cases that the original authors hadn't anticipated.

The irony is that pointer compression itself had been broken in Node since version 2. Nobody noticed because nobody used it. The fix came as part of this work.

Once the isolate group changes landed, the Node team could finally enable pointer compression safely. They packaged it as "Node Caged," a Docker image with the feature turned on. No recompilation required—just swap the image.

The Benchmarks

Real-world testing used a Next.js e-commerce application with server-side rendering, 10,000 mock products, and simulated database delays. The setup ran on AWS EKS with production-like traffic patterns.

Results for standard Node versus Node Caged:

• Average latency: 39.7ms → 40.7ms (2.5% slower)
• P90 latency: 78ms → 82ms (5% slower)
• P99 latency: 92ms → 85ms (7.6% faster)
• Memory usage: -50%

The P99 improvement is the telling metric. Garbage collection—the process where V8 reclaims unused memory—blocks other operations while running. A smaller heap means less work for the garbage collector, which means shorter pauses. The 99th percentile captures those worst-case pauses. They got faster.

"For most teams, this trade-off is an easy choice," the analysis concludes. Half the memory, slightly slower averages, but better worst-case latency.

The Historical Echo

This isn't the first time default settings in Node left performance on the table. A previous benchmark controversy revealed that Cloudflare's V8-based runtime ran trigonometry functions faster than Node—not because of better hardware, but because Cloudflare had enabled a math optimization flag that Node hadn't. Cloudflare upstreamed the fix.

The pattern repeats: companies with specific performance needs investigate, find optimizations, contribute them back. Node benefits. The ecosystem benefits. But it takes longer than it should because the engineering happens invisibly, at the C++ layer where few JavaScript developers ever look.

What This Changes

Pointer compression will likely become the default in a future Node release. The Docker image exists now for teams willing to test early. Most Node services use less than a gigabyte of memory, well under the 4GB per-isolate limit.

The broader question is how many other optimization flags exist in V8 that Node hasn't enabled. The engine has hundreds of configuration options. Most developers don't know they exist. "People don't appreciate how much config there is in Node because none of us ever hit it," as one engineer noted.

Which means there may be other 50% improvements waiting in the configuration space, undiscovered because the default settings were chosen a decade ago for different constraints.

The 62-line pull request represents months of work by engineers most developers will never hear about. It's infrastructure work—the kind that doesn't generate headlines but compounds in value across millions of deployments. Chrome got this in 2020. Node gets it in 2025. The delay cost real money in server costs across the ecosystem.

The question isn't whether more optimizations exist. They almost certainly do. The question is whether anyone has the incentive to find them.

—Bob Reynolds, Senior Technology Correspondent