How we check

Proving the results are identical

Every package is tested the same way. The original is installed next to the replacement, both receive the same input, and everything observable is compared: return values, byte for byte; thrown errors, including their class, message and position; callbacks; and for stateful objects, the state after every call. The inputs are mostly real code, such as tens of thousands of files from node_modules and from a large project's pnpm store, plus fuzzed and deliberately malformed variants and, for some packages, the original project's own test inputs.

The tests for each package are listed in its README. The counts below are from the last full run, and all of them passed with no mismatches.

Checks written separately

A second set of tests, in the repository's verify/ folder, was written apart from the package suites. It calls each package the way a real application does, using Nodepod's calls: its content packing for pako, its exact topLevelParser for acorn, lockfile integrity hashes of real npm tarballs for noble-hashes, and the public transform() API for esbuild. It found no differences either, across 37,913 pako, 54,816 acorn, 40,041 lexer, 7,906 Brotli, 17,308 hash and 8,075 esbuild checks. Every browser build was also run in headless Chromium, and the packed tarballs were installed under the original names and used from Node and from a bundler.

Testing the tests

A passing suite proves little if it could not fail. For fast-noble-hashes the suite is mutation tested: 41 deliberate bugs are planted in the glue, the patched files and the WebAssembly, and the suite has to catch every one. It does.

What is not identical

There are differences, and each package's README lists them. They are mostly places where the original loops forever, corrupts data or reads memory it does not own, and the replacement throws a clear error or gives a stable answer instead. Each one is pinned by a test, so it cannot change unnoticed.

How the timings are taken

The tables on each package's page come from the repository's benchmark suites. They run on a Ryzen 7 7800X3D with Node 24.16 and Chromium 149. The two implementations alternate in fresh processes, so neither inherits the other's warmed-up JIT state or heap, and each row keeps the best of three rounds. Alternating means a background task or a change in CPU frequency hits both sides alike.

The live comparisons on this site work a little differently, because they run in your tab: both libraries take turns in short batches in the same page, each is warmed up first, and each keeps its best batch. That is quicker and shows real numbers on your hardware, but it is less controlled, so treat the recorded tables as the reference and the live numbers as a check that they hold up on your machine.

One caveat sits in the esbuild results. In Node, esbuild-wasm waits for the operating system's timer, which is 15.6 ms on Windows, on every call. That inflates the speedup on small inputs, which is why the browser tables are the fairer comparison and why native esbuild is listed next to the Node numbers.

Most of the packages start about as fast as the originals. pako and Brotli start faster; each hash family builds and compiles its WebAssembly at first use, so noble-hashes' first call is slower, and that cost is paid back after a few kilobytes of input.

Speed is not free in bytes, and the results are mixed. The tarballs that npm downloads are almost all smaller, because none of them carries a copy of the original. In a browser bundle, the packages whose fast path is compiled WebAssembly are larger after compression, because wasm compresses worse than JavaScript.

Where a fast package is still larger, it is the fast engine itself: compiled wasm compresses worse than the original's JavaScript (pako's zlib, the SIMD lexer), and the per-family glue outweighs noble's tiny SHA-256 function. Shrinking these further cost more speed than the rules allow, which are that every call stays faster than the original and none becomes more than 10% slower than the previous version.

Dead ends

Things tried that did not pay off are kept in the repository so nobody repeats them. Here they are, grouped by package.

pako

• Deflate at levels 6 to 9 is bounded by zlib's match finder, which must visit the same candidates for the output to be identical: about 2x at level 6, 1.7 to 2x at level 9, which is native zlib speed.
• For inflate, these were all slower or no better: fused length entries (10 to 17% slower), decoding 4 or 5 literals per refill, 9 or 10-bit distance tables and 10 or 12-bit literal tables, and wasm-opt -O4.
• For size, compiling the core for size cost 1.7 KB but made deflate 13 to 43% slower, and inflating the embedded module with pako's own JavaScript took 4.6 to 6 ms cold. The compressed wasm alone is 21 KB, larger than pako's gzipped JavaScript, so the bundle stays about twice pako's gzip size.

acorn

• Lazily created token start positions, interning identifiers, and object literals for AST nodes (node creation was 4x slower) did nothing or made it worse.
• Shipping several files (import time 7.5 to 8.9 ms) or an unminified bundle (about 6.0 ms) instead of one minified file was slower to import. esbuild's bundler converts to var, which costs 5 to 10% on large parses, so the package is bundled with Rollup. Reusing the parse state made parsing 4 to 16% slower.
• The gzip and brotli sizes stay about 20% above acorn's, although the minified size is below it, because the fast machinery compresses less well. The cost of locations is dominated by garbage collecting the position objects that the AST has to contain.

esbuild

• From when the package still shipped esbuild's Go binary: tuning Go's garbage collector (1.3x on big inputs, but it grows wasm memory that never shrinks), wasm-opt -O2 on the Go binary (no speed gain, 3.4% smaller), and a TinyGo build, which builds but whose runtime cannot run esbuild's asynchronous stdin loop.
• Object literals for AST nodes and interning identifier strings gave no gain. The eventual answer was to remove the Go binary altogether.

es-module-lexer

• A JavaScript charCodeAt copy of the source (about 2.5 ns per character) and btoa plus setFromBase64 (about 1 ns per character) both lost to the copy paths now used. Relaxed-SIMD swizzle would add 3 to 12%, but would need a second module for engines without it.
• V8's baseline code for the builtins copy loop is slow, so the first million characters use intoCharCodeArray instead.
• For size, compiling at opt-level z saved 0.2 KB gzipped and was up to 13% slower, and dropping the Chromium copy module saved 0.5 KB but was 37 to 135% slower in Chromium. A wasm small enough to match the original's 6.5 KB bundle would mean giving up SIMD.

brotli

• A native x86 build of the same encoder is no faster than the wasm, so what is left is the algorithm. Reordering relaxations across queue entries would be faster but can change tie-breaks, and so the output.
• Probing out of line, 16-byte queue entries, dictionary prefix tables and prefetching gave no gain.

noble-hashes

• A precomputed message schedule for SHA-256 was about 30% slower than keeping it in locals. Reusing the previous round's a ^ b in Maj gave 5% on SHA-256 and nothing on SHA-512, and wasm-opt -O3 changed nothing.
• SHA-256 stays near 1.5x: scalar SHA-256 in wasm against a JIT that already does 32-bit rotates well. The create() path is floored by noble's constructor, about 270 ns in Node, mostly the ArrayBuffer behind its buffer. Pooling those buffers would be faster but would let instances share memory.
• Rolled SHA-2 rounds ran at 0.79 to 0.97x of the speed, so the kernels ship as templates that are expanded to unrolled code at first use. A lone sha256 import stays above noble's size: noble's JavaScript SHA-256 is about 0.6 KB brotli-compressed, and the glue alone is about 1.9 KB.

A bug worth remembering

• Bundlers drop calls annotated /* @__PURE__ */ whose result is unused. fast-noble-hashes' wasm start-up was exactly such a call, so every bundled build silently ran noble's JavaScript. It is fixed, and noble, es-module-lexer and acorn now have bundle tests that would catch it.