Node.js Left 26% Performance on the Table for 10 Years

A default set in May 2015 just got its first change. One constant. One number. And it was silently costing Node.js up to 26% throughput on some of the most common workloads in the ecosystem: file reads, HTTP parsing, stream chunking. Nobody broke it. Nobody was ignoring it. It was just stuck in a world that no longer existed. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina explain how they investigated a small but important change that was just released in Node.js 26.3.0. They discuss how modern applications moved past an old assumption, why multi-threaded apps suffered the most, and what it takes to show that a simple fix is safe for millions of users. In this episode, we cover: ✅ How a default set in 2015 quietly stopped making sense as applications and hardware evolved ✅ Why the fix helped some workloads by 26%, and had zero impact on others ✅ How Matteo traced the slowdown all the way down to the operating system level to understand what was really happening ✅ The cost of the change, and how to think about whether it matters for your own application The takeaway? The biggest performance gains often don’t come from major rewrites. Sometimes, it’s just a setting that made sense years ago and was never revisited. The real lesson is about the assumptions built into the tools you use daily, and what can change when someone finally checks them.