Boosting JSON.stringify Performance: How V8 Achieved a 2x Speedup

Introduction

JSON.stringify is a cornerstone of JavaScript, used daily to serialize data for network requests, localStorage, or just passing objects between functions. Its performance directly impacts user experience — a faster stringify means quicker page loads and snappier applications. The V8 team recently announced a significant optimization that makes JSON.stringify more than twice as fast in many common scenarios. This article dives into the two key technical improvements behind this speedup: a side-effect-free fast path and a templatized string handler.

The Key Insight: Side-Effect-Free Fast Path

The foundation of the optimization is a simple but powerful idea: if the serializer can guarantee that the serialization process will not trigger any side effects, it can skip a huge amount of defensive code. This dedicated "fast path" avoids expensive runtime checks and branches that the general-purpose serializer must perform.

What Are Side Effects?

In the context of JSON.stringify, a side effect is anything that breaks the straightforward traversal of an object tree. The most obvious examples are:

• User-defined toJSON methods that execute arbitrary code
• Getters on objects that might trigger function calls
• Internal operations that could force a garbage collection (GC) cycle, such as flattening a ConsString

As long as V8 can statically determine that none of these side effects will occur — for instance, when serializing a plain old data object without custom toJSON — it stays on the fast path. This bypasses the overhead of checking for hooks, resolving getters, and handling GC interruptions, yielding a significant boost for the most common JavaScript objects.

Iterative vs. Recursive Serialization

The new fast path also shifts from a recursive to an iterative approach. Recursive serialization requires stack overflow checks and can limit the depth of nested objects. By using an iterative algorithm, V8 eliminates these checks entirely and can handle much deeper object graphs. This not only improves speed but also expands the practical limits of what developers can serialize.

Optimizing String Encodings for Speed

The second major optimization targets how strings are stored and processed. Strings in V8 can be represented using either one-byte (ASCII) or two-byte (UTF‑16) characters. If a string contains any non‑ASCII character, the entire string is stored with two bytes per character — doubling memory usage and altering processing costs.

One‑Byte vs. Two‑Byte Strings

Previously, the stringifier had to constantly examine the current string’s character width, branching between two code paths. This branching added overhead, especially when serializing mix of ASCII and non‑ASCII strings. To eliminate these runtime decisions, the V8 team templatized the entire stringifier on the character type. Now, two completely separate versions of the serializer are compiled: one optimized exclusively for one‑byte strings, and another for two‑byte strings. While this increases binary size, the performance gain justifies the trade‑off.

Handling Mixed Encodings Gracefully

During serialization, the serializer must still inspect each string’s internal representation to detect types that cannot be handled on the fast path — for example, a ConsString that may require GC during flattening and thus falls back to the slow path. This necessary check is now more efficient because the templatized serializer is already specialized for the character width, so the only extra work is the fallback decision. The result is a smoother, faster experience across all string encodings.

Conclusion and Limitations

These optimizations — the side-effect-free fast path and the templatized string handler — combine to make JSON.stringify more than twice as fast for the vast majority of real‑world use cases. However, the fast path only applies when no side effects are encountered. Developers who rely heavily on custom toJSON methods or objects with getters will still benefit from other improvements but won’t see the full 2x gain. For more details on when the fast path does or does not apply, see the official Limitations section in the V8 documentation. Overall, this update represents a meaningful step forward for JavaScript performance, making everyday operations faster for everyone.

Limitations

While the new fast path dramatically improves speed for plain objects, it is bypassed when serialization triggers side effects, such as:

• Objects with a custom toJSON property
• Objects that use getters or proxies
• Dates (which return a string via toJSON)
• Objects that may cause garbage collection during string flattening

In those cases, V8 falls back to the slower but correct general-purpose serializer. The team continues to look for ways to expand the fast path to cover more scenarios.