@zip.js/zip.js 2.14.0 → 2.15.0

package/BENCHMARKS.md

@@ -1,26 +1,21 @@
 # Benchmarks
 
-A fair, reproducible comparison of **@zip.js/zip.js** against
-[jszip](https://github.com/Stuk/jszip), [fflate](https://github.com/101arrowz/fflate)
-and [archiver](https://github.com/archiverjs/node-archiver) on a set of realistic
-workloads.
-
-The numbers below are honest: zip.js wins clearly on some workloads and loses on
-others. The goal is to show *where* each library is the right tool, and to give you a
-harness you can re-run on your own hardware — the results are machine-specific and you
-should not trust anyone's benchmark (including this one) without reproducing it.
-
-> **TL;DR** — For compressing large or multiple entries, zip.js is the fastest option
-> in the field, and it is the only one that parallelizes compression across CPU cores
-> **without spawning a single Web Worker** — it lets the platform's native
-> `CompressionStream` run on the threadpool while you simply issue concurrent `add()`
-> calls. It also streams arbitrarily large files at a flat, low memory ceiling. For
-> archives made of thousands of tiny entries, **fflate** is several times faster and much
-> lighter — but that gap is zip.js's per-entry orchestration, not its codec: measured on
-> their own, the codecs are the other way round (see [Codecs](#codecs-compared-at-equal-output-size)).
-> Against native tooling, zip.js on a modern runtime is a bit
-> faster *and* tighter than 7-Zip's fast mode on single-file streaming; 7-Zip keeps a
-> real edge only on thousands of tiny files.
+Measurements of [@zip.js/zip.js](https://www.npmjs.com/package/@zip.js/zip.js) against
+[jszip](https://github.com/Stuk/jszip), [fflate](https://github.com/101arrowz/fflate) and
+[archiver](https://github.com/archiverjs/node-archiver), of zip.js's own codec backends, and of
+the runtimes it runs on. Every number on this page comes from the harness in
+[`benchmarks/`](benchmarks/), on the machine, date and versions below. The results are specific
+to them; run the harness on your machine before relying on any of them.
+
+The page answers four questions, each from one or two scripts of the harness:
+
+- [How does zip.js compare with jszip, fflate and archiver?](#zipjs-against-jszip-fflate-and-archiver)
+  `bench.js`, on Node.
+- [Which codec backend of zip.js is fastest, and what does concurrent `add()` buy?](#the-codec-backends-of-zipjs)
+  `bench-codecs.js` and `bench-backends.js`, on Node.
+- [How do Node, Bun and Deno differ?](#node-bun-and-deno) `bench-runtimes.js`.
+- [How fast is AES encryption?](#encryption-aes-256-on-a-stored-entry) `bench-aes.js` and
+  `bench-aes.html`, on the three runtimes and two browsers.
 
 ## Environment
 
@@ -28,477 +23,378 @@ should not trust anyone's benchmark (including this one) without reproducing it.
 |---|---|
 | Machine | Apple M2, 8 cores (4 performance + 4 efficiency), 16 GB RAM |
 | OS | macOS 26.6.2 (arm64) |
-| Runtime | Node.js v26.7.0 |
-| zip.js | 2.11.2 |
-| jszip | 3.10.1 |
+| Runtimes | Node.js v26.7.0, Bun 1.4.2, Deno 2.9.6 |
+| Browsers | Firefox 154, Chrome 153 (the browser encryption table only) |
+| zip.js | 2.14.0 |
+| jszip | 3.10.2 |
 | fflate | 0.8.3 |
 | archiver | 8.0.0 |
-| Measured | 2026-09-06 — the 7-Zip section under Deno 2.9.6, everything else on Node; the encryption section on 2026-09-09, also under Bun 1.4.2, Deno 2.9.6, Firefox 154 and Chrome 153 |
+| Measured | 2026-09-10; the two encryption tables on 2026-09-12, on the engines that follow 2.14.0 |
 
 ## Method
 
-- **Isolation.** Each `(library, operation, workload)` combination runs in its own
-  freshly-spawned Node process under `/usr/bin/time -l`, so there is no cross-library
-  GC or heap contamination and peak memory is a true per-library figure.
-- **Timing.** `performance.now()` around the measured operation only. Every combination
-  runs **3 times**; the table reports the **median**.
-- **Memory.** Peak resident set size (RSS) reported by `/usr/bin/time -l`. The "peak"
-  column is the delta over an empty-process baseline (~50 MB on this runtime), i.e. the
-  memory attributable to the work.
-- **Fair work.** All libraries compress at **DEFLATE level 6**, and output sizes are shown
-  next to the times. Read them: a "level" is not a unit shared between libraries. zlib's
-  level 6 and fflate's level 6 are different parameter sets, so the two do not produce the
-  same amount of compression and a time is only comparable next to the size it achieved.
-  The [Codecs](#codecs-compared-at-equal-output-size) section compares them by output size
-  instead, which is the only axis on which "faster" means anything. The corpus is generated
-  from a seeded PRNG, so every library sees byte-for-byte identical input.
-- **zip.js modes.** zip.js is measured both **single-threaded** (apples-to-apples with
-  the single-threaded libraries) and with its **Web Worker** pool, so the worker
-  overhead is never hidden.
-
-## Compression — single process, single thread
-
-Level-6 DEFLATE, one entry (or one batch) compressed in the main thread. This is the
-apples-to-apples comparison against the single-threaded libraries.
-
-Time, with the size each library produced — the two are only meaningful together.
-
-| Workload | @zip.js/zip.js | jszip | fflate | archiver |
-|---|--:|--:|--:|--:|
-| Compressible text (20 MB) | 703 ms / 6.1 MB | 1714 ms / 6.2 MB | 908 ms / 6.3 MB | **702 ms** / 6.1 MB |
-| Incompressible data (20 MB) | 364 ms / 21.0 MB | 858 ms / 21.0 MB | **298 ms** / 21.0 MB | 357 ms / 21.0 MB |
-| Already-compressed media (20 MB) | 362 ms / 21.0 MB | 860 ms / 21.0 MB | **297 ms** / 21.0 MB | 356 ms / 21.0 MB |
-| 5,000 files × ~2 KB | 834 ms / 4.9 MB | 826 ms / 4.7 MB | **305 ms** / 4.8 MB | 431 ms / 4.8 MB |
+- **Workloads.** Synthetic data from a seeded generator (`benchmarks/lib/corpus.js`), so every
+  library and every run sees the same bytes. "Text" is English-looking words that deflate
+  compresses about 3.4×, "incompressible" is random bytes, "5,000 files" is 5,000 text files of
+  about 2 KB each, and the 8 × 8 MB and 256 MB workloads are text.
+- **Isolation.** In `bench.js` and `bench-backends.js`, each (library, operation, workload)
+  combination runs in its own freshly spawned Node process under macOS's `/usr/bin/time -l`, so
+  the libraries never share a heap and peak memory is per library. Every row of those two
+  scripts includes what a fresh process pays on its first operation: the JIT warm-up of each
+  library and, for the zip.js WebAssembly rows, the module instantiation, about 20 ms. The
+  codec, encryption and runtime scripts run in-process, with one warmup run before the timed
+  ones.
+- **Timing.** `performance.now()` around the measured operation. Each combination runs 3 times
+  (5 in the encryption script) and the tables report the median. Differences of a few percent
+  are within run-to-run noise. A bold cell is the best number among the alternatives it is
+  compared with, one per column in the head-to-head tables and one per runtime in the runtime
+  table; it is not a verdict.
+- **Memory.** Peak resident set size reported by `/usr/bin/time -l`, as a delta over an empty
+  Node process (about 50 MB). It is the highest of the 3 runs, while the time is their median.
+- **Level.** Every library compresses at its own level 6. A level is not a unit shared between
+  libraries: zlib's level 6 and fflate's level 6 are different parameter sets and produce
+  different sizes, so every time is printed next to the size it achieved, and the
+  [Codecs](#codecs-at-equal-output-size) table compares by output size instead.
+- **Codecs.** Every head-to-head table names the codec of each row. archiver runs Node's `zlib`
+  module, the host's zlib written in C; jszip (pako) and fflate deflate and inflate in
+  JavaScript. zip.js selects its codec at runtime, so it has one row per backend: the
+  `CompressionStream` and `DecompressionStream` of the runtime, Node's zlib here and the default
+  where they exist; the bundled WebAssembly zlib; and the pure-JavaScript zlib port. The last two
+  ship with the library, like the codecs of jszip and fflate, so those rows compare the
+  libraries without the host's zlib in the picture.
+- **Checks.** No decompression row verifies the CRC-32 of the entries: zip.js and jszip leave
+  the check off by default, and fflate has none on read. Turning it on in zip.js adds one pass
+  over the output, about 15 ms per 20 MB.
+- **Units.** MB in the tables is 10^6 bytes. The workload sizes (20 MB, 8 MB, 256 MB) and the
+  MB/s throughputs use 2^20 bytes.
+
+## zip.js against jszip, fflate and archiver
+
+One Node process per measurement (`benchmarks/bench.js`), one thread, every library at its
+level 6. zip.js appears once per codec backend.
+
+### Compression
+
+One entry, or one batch of entries, compressed by a single sequence of calls. Time, with the
+size each row produced:
+
+| Library | Codec | Compressible text (20 MB) | Incompressible data (20 MB) | 5,000 files × ~2 KB |
+|---|---|--:|--:|--:|
+| @zip.js/zip.js | `CompressionStream` | **700 ms** / 6.1 MB | 365 ms / 21.0 MB | 888 ms / 4.9 MB |
+| @zip.js/zip.js | WASM zlib | 1057 ms / 6.2 MB | 475 ms / 21.0 MB | 679 ms / 4.9 MB |
+| @zip.js/zip.js | pure-JS zlib | 1238 ms / 6.2 MB | 802 ms / 21.0 MB | 1125 ms / 4.9 MB |
+| jszip | pako (JavaScript) | 1723 ms / 6.2 MB | 862 ms / 21.0 MB | 843 ms / 4.7 MB |
+| fflate | fflate (JavaScript) | 909 ms / 6.3 MB | **297 ms** / 21.0 MB | **281 ms** / 4.8 MB |
+| archiver | Node `zlib` (C) | 702 ms / 6.1 MB | 359 ms / 21.0 MB | 424 ms / 4.8 MB |
 
 Peak memory for the same runs (Δ over baseline):
 
-| Workload | @zip.js/zip.js | jszip | fflate | archiver |
-|---|--:|--:|--:|--:|
-| Compressible text (20 MB) | 90 MB | 69 MB | **62 MB** | 72 MB |
-| Incompressible data (20 MB) | 153 MB | 92 MB | 108 MB | **81 MB** |
-| Already-compressed media (20 MB) | 154 MB | 93 MB | 108 MB | **74 MB** |
-| 5,000 files × ~2 KB | 252 MB | 267 MB | **102 MB** | 137 MB |
-
-On compressible text zip.js and archiver are tied (703 ms against 702 ms, inside the
-noise) and both produce the smallest archive; fflate is 29 % slower here *and* 3 % larger,
-which is the level-6-is-not-a-unit effect described above. On incompressible data — where
-no codec has anything to do — fflate wins on both axes. On 5,000 tiny files fflate is 2.7×
-faster than zip.js and uses a third of the memory; that gap is per-entry orchestration
-(worker round trips, header writes, one stream per entry), not codec speed, as the
-[Codecs](#codecs-compared-at-equal-output-size) section shows.
-
-## Parallelism & codec backends — 8 files × 8 MB, single process
-
-This is the headline. The same 64 MB of compressible entries, compressed several ways
-in a **plain Node process** (no worker threads unless noted). zip.js can select its
-codec backend at runtime — native `CompressionStream`, the bundled WebAssembly zlib, or
-a pure-JavaScript zlib port — and it can issue `add()` calls concurrently.
+| Library | Codec | Compressible text (20 MB) | Incompressible data (20 MB) | 5,000 files × ~2 KB |
+|---|---|--:|--:|--:|
+| @zip.js/zip.js | `CompressionStream` | 91 MB | 153 MB | 245 MB |
+| @zip.js/zip.js | WASM zlib | 119 MB | 170 MB | 250 MB |
+| @zip.js/zip.js | pure-JS zlib | 114 MB | 172 MB | 276 MB |
+| jszip | pako (JavaScript) | 69 MB | 93 MB | 269 MB |
+| fflate | fflate (JavaScript) | **62 MB** | 108 MB | **102 MB** |
+| archiver | Node `zlib` (C) | 72 MB | **74 MB** | 137 MB |
+
+On the text file zip.js with `CompressionStream` and archiver take the same time, 700 and
+702 ms, for the same output size: both run Node's zlib. With the codecs that ship with each
+library, fflate takes 909 ms for 2 % more bytes, zip.js's WebAssembly zlib 1057 ms, its
+pure-JavaScript port 1238 ms and jszip 1723 ms. On incompressible data fflate is the fastest row
+and archiver the smallest in memory. On 5,000 small files the WebAssembly backend is 23 % faster
+than `CompressionStream`, so a native stream costs more per entry than a WebAssembly one; fflate
+takes 41 % of the WebAssembly row's time there against 86 % on the 20 MB file, and the
+difference is the work zip.js does per entry, a stream and a header each. The zip.js rows use
+the most memory on the two 20 MB files.
+
+### Decompression
 
-| Configuration | Median time | Output | vs jszip |
-|---|--:|--:|--:|
-| **zip.js — `CompressionStream`, concurrent `add()`** | **607 ms** | 19.6 MB | **9.3×** |
-| fflate — async (its own worker pool) | 733 ms | 20.0 MB | 7.7× |
-| zip.js — `CompressionStream`, sequential | 2214 ms | 19.6 MB | 2.6× |
-| archiver — Node zlib (libuv threadpool) | 2278 ms | 19.6 MB | 2.5× |
-| fflate — `zipSync` (single thread) | 3118 ms | 20.0 MB | 1.8× |
-| zip.js — WASM zlib | 3358 ms | 19.7 MB | 1.7× |
-| zip.js — pure-JS zlib | 3840 ms | 19.7 MB | 1.5× |
-| jszip (pako, single thread) | 5671 ms | 19.7 MB | 1.0× |
-
-The two fflate rows produce 20.0 MB where every other row produces 19.6–19.7 MB, i.e. ~2 %
-more, so they are not doing quite the same work as the rows above and below them.
-
-**The point:** zip.js with the native `CompressionStream` goes from **2214 ms
-sequential to 607 ms with concurrent `add()` — a 3.6× speedup — using no Web Workers at
-all.** The native codec runs on the platform's threadpool, so independent entries
-compress on multiple cores while your code stays on the main thread. That makes it the
-fastest configuration measured, ahead of fflate's dedicated worker pool.
-
-One honest caveat, visible in the table: **only the native `CompressionStream` backend
-parallelizes this way.** The WASM and pure-JS backends run synchronously on the main
-thread, so concurrent `add()` does not speed them up (3358 ms and 3840 ms whether
-sequential or "parallel"). Use those backends when a native `CompressionStream` is
-unavailable or when you need byte-identical zlib output; use the native backend when you
-want this parallelism.
-
-There is a second way to land on the WASM backend by accident: because
-`CompressionStream` exposes no level control, requesting any non-default compression
-level (e.g. `{ level: 5 }`) makes zip.js fall back to the WASM zlib codec — which, per
-the table, does not parallelize via concurrent `add()`. Keep the default level to keep
-the native-backend parallelism, or pair a custom level with Web Workers (below).
-
-That fallback costs more than a backend switch, and the
-[frontier](#the-frontier--one-axis-both-sides) measures how much: how much speed a lower
-level actually buys depends on how fast the host's own zlib is, and on Deno it buys
-nothing at all — `level: 5` there is slower *and* larger than the default.
-
-### Parallelism is runtime-dependent
-
-The table above is measured on **Node**, and its "no Web Workers needed" result does
-**not** hold on every runtime: concurrent `add()` only spreads across cores if the
-runtime runs `CompressionStream` off the main thread. Same 8 × 8 MB workload, level 6,
-median of 3:
-
-| Runtime | sequential | concurrent `add()` | concurrent `add()` + `useWebWorkers` |
-|---|--:|--:|--:|
-| Node.js | 2.94 s | **0.74 s** | 0.74 s |
-| Bun | 1.80 s | **0.36 s** | 0.46 s |
-| Deno | 1.84 s | 1.82 s | **0.47 s** |
-
-- **Node and Bun** back `CompressionStream` with a threadpool, so concurrent `add()`
-  alone parallelizes — no Web Workers needed (Bun is fastest here).
-- **Deno** runs `CompressionStream` on the isolate thread, so concurrent `add()` alone
-  gives no speedup (1.82 s ≈ its 1.84 s sequential). Set `useWebWorkers: true` and it
-  parallelizes properly (0.47 s), landing right beside the others.
-- **Browsers vary by engine.** Safari/WebKit runs `CompressionStream` on the main thread
-  (serial, like Deno), so use `useWebWorkers: true` there. Chromium implements it
-  separately and may behave differently — check a given browser by compressing several
-  large buffers through `CompressionStream` sequentially versus concurrently and comparing
-  the wall time.
-
-**Rule of thumb:** on Node and Bun, concurrent `add()` is enough; on Deno and
-Safari/WebKit, also set `useWebWorkers: true`. Web Workers are the portable way to get
-this parallelism on any runtime — and the only way once you use a non-default level
-(which switches to the WASM codec).
-
-## Codecs, compared at equal output size
-
-The tables above compare *libraries* — a whole zip pipeline, at each library's default
-"level 6". This one compares only the **codecs**, on the same 20 MB buffer with no zip
-container around them, and sorts by output size rather than by level. That matters because
-zlib's level 6 and fflate's level 6 are different parameter sets: matched by level, the
-comparison silently reads a ratio difference as a speed difference.
-
-`frontier` marks a row that nothing smaller beats on time.
-
-| Codec | Setting | Output | Ratio | Time | Throughput | |
+Level-6 archives, read back and fully materialized. archiver has no unzip API, so it is
+excluded.
+
+| Library | Codec | Compressible text (20 MB) | 5,000 files × ~2 KB |
+|---|---|--:|--:|
+| @zip.js/zip.js | `DecompressionStream` | **66 ms** | 628 ms |
+| @zip.js/zip.js | WASM zlib | 78 ms | 476 ms |
+| @zip.js/zip.js | pure-JS zlib | 180 ms | 615 ms |
+| jszip | pako (JavaScript) | 137 ms | 444 ms |
+| fflate | fflate (JavaScript) | 116 ms | **102 ms** |
+
+Peak memory for the same runs (Δ over baseline):
+
+| Library | Codec | Compressible text (20 MB) | 5,000 files × ~2 KB |
+|---|---|--:|--:|
+| @zip.js/zip.js | `DecompressionStream` | 116 MB | 350 MB |
+| @zip.js/zip.js | WASM zlib | 163 MB | 484 MB |
+| @zip.js/zip.js | pure-JS zlib | 154 MB | 451 MB |
+| jszip | pako (JavaScript) | 103 MB | 306 MB |
+| fflate | fflate (JavaScript) | **92 MB** | **120 MB** |
+
+On the 20 MB stream `DecompressionStream` takes 66 ms and the WebAssembly inflate 78 ms, then
+fflate 116 ms, jszip 137 ms and the pure-JavaScript port 180 ms. The WebAssembly row includes
+the module instantiation a fresh process pays once, about 20 ms. Warm, the two inflates are
+within 6 % of each other in the [Codecs](#codecs-at-equal-output-size) table. On 5,000 small
+files the order reverses: fflate takes 102 ms, jszip 444 ms and the three zip.js rows 476 to
+628 ms, with `DecompressionStream` the slowest of them, the same per-entry cost as in
+compression. fflate uses the least memory on both workloads, 34 % of the `DecompressionStream`
+row on the small files, and the WebAssembly and pure-JavaScript rows peak higher than
+`DecompressionStream`. The three zip.js rows allocate the same 800 MB of stream objects over the
+5,000 entries, about 160 KB per entry. The WebAssembly and pure-JavaScript codecs run on the
+JavaScript thread, so V8's incremental marking keeps more of that garbage alive between
+collections, and that is the difference between the rows.
+
+### Streaming a 256 MB file, disk to disk
+
+One file read with `fs.createReadStream` in 64 KB chunks and one archive written with
+`fs.createWriteStream`, one entry, each library's streaming API. zip.js takes Web Streams, so its
+rows go through Node's `Readable.toWeb` and `Writable.toWeb` bridges; the other libraries take
+the Node streams directly.
+
+| Library | Codec | Median time | Peak memory (Δ) | Output |
+|---|---|--:|--:|--:|
+| @zip.js/zip.js | `CompressionStream` | **9055 ms** | 62 MB | 78.3 MB |
+| archiver | Node `zlib` (C) | 9115 ms | 71 MB | 78.3 MB |
+| fflate | fflate (JavaScript) | 12456 ms | **41 MB** | 80.2 MB |
+| @zip.js/zip.js | WASM zlib | 13629 ms | 88 MB | 78.9 MB |
+| @zip.js/zip.js | pure-JS zlib | 15485 ms | 120 MB | 78.9 MB |
+| jszip | pako (JavaScript) | 22539 ms | 74 MB | 78.9 MB |
+
+Every row streams: the peaks stay between 41 MB (fflate) and 120 MB (the pure-JavaScript port)
+over baseline on the 256 MB input. zip.js with `CompressionStream` and archiver take the same
+time within 1 %; jszip takes 2.5× that. With its WebAssembly zlib zip.js takes 1.5× the
+`CompressionStream` time and 1.1× fflate's, for 1.6 % fewer bytes; the pure-JavaScript port
+takes 1.2× fflate's time.
+
+## The codec backends of zip.js
+
+zip.js selects its codec at runtime: the `CompressionStream` and `DecompressionStream` of the
+host when they exist and the level is the default, otherwise the bundled WebAssembly zlib, and
+the pure-JavaScript zlib port where WebAssembly cannot load or when it is configured. This
+section measures them on Node, alone and then inside the zip pipeline.
+
+### Codecs at equal output size
+
+The same 20 MB text buffer with no zip container around it (`benchmarks/bench-codecs.js`),
+sorted by output size rather than by level, because zlib's level 6 and fflate's level 6 are
+different parameter sets: matched by level, the comparison reads a ratio difference as a speed
+difference.
+
+A row is beaten when another row is at least as small and faster; the last column names the
+fastest such row. A row with an empty last column is beaten by nothing on the table.
+
+| Codec | Setting | Output | Ratio | Time | Throughput | Beaten by |
 |---|---|--:|--:|--:|--:|---|
-| WASM zlib | level 8 | 6,115,980 | 3.429 | 1466 ms | 13.6 MB/s | frontier |
-| `CompressionStream` | no level control | 6,120,503 | 3.426 | 692 ms | 28.9 MB/s | frontier |
-| WASM zlib | level 6 | 6,165,103 | 3.402 | 1023 ms | 19.5 MB/s | |
-| fflate | level 8 — its best | 6,239,025 | 3.361 | 750 ms | 26.7 MB/s | |
-| fflate | level 6 | 6,257,881 | 3.351 | 738 ms | 27.1 MB/s | |
-| WASM zlib | level 5 | 6,562,182 | 3.196 | 494 ms | 40.5 MB/s | frontier |
-| fflate | level 5 | 6,648,574 | 3.154 | 534 ms | 37.4 MB/s | |
-| WASM zlib | level 4 | 6,907,987 | 3.036 | 276 ms | 72.4 MB/s | frontier |
-| fflate | level 1 | 7,261,700 | 2.888 | 316 ms | 63.3 MB/s | |
-| WASM zlib | level 1 | 7,531,042 | 2.785 | 177 ms | 113.1 MB/s | frontier |
-
-The pure-JS port produces byte-identical output to the WASM codec at every level and is
-1.2–2× slower; the full 28-row table is in `benchmarks/results/codecs-results.json`.
-
-Two things to take from it. **fflate never lands on the frontier here** — at every size it
-reaches, one of zip.js's codecs gets there sooner — and above ratio 3.361 it has no setting
-at all, while the WASM codec keeps going to 3.429. Second, the level numbers really are
-incomparable: fflate's level 6 falls between zlib's levels 5 and 6 on ratio, which is
-exactly why the library tables above show it as both faster *and* larger.
+| WASM zlib | level 8 | 6,115,980 | 3.429 | 1504 ms | 13.3 MB/s | |
+| `CompressionStream` | no level control | 6,120,503 | 3.426 | 716 ms | 27.9 MB/s | |
+| WASM zlib | level 6 | 6,165,103 | 3.402 | 1047 ms | 19.1 MB/s | `CompressionStream` |
+| fflate | level 8, its best | 6,239,025 | 3.361 | 767 ms | 26.1 MB/s | `CompressionStream` |
+| fflate | level 6 | 6,257,881 | 3.351 | 815 ms | 24.6 MB/s | `CompressionStream` |
+| WASM zlib | level 5 | 6,562,182 | 3.196 | 505 ms | 39.6 MB/s | |
+| fflate | level 5 | 6,648,574 | 3.154 | 541 ms | 36.9 MB/s | WASM zlib level 5 |
+| WASM zlib | level 4 | 6,907,987 | 3.036 | 278 ms | 71.9 MB/s | |
+| fflate | level 1 | 7,261,700 | 2.888 | 318 ms | 62.9 MB/s | WASM zlib level 4 |
+| WASM zlib | level 2 | 7,359,387 | 2.850 | 195 ms | 102.5 MB/s | |
+| WASM zlib | level 1 | 7,531,042 | 2.785 | 175 ms | 114.1 MB/s | |
+
+The pure-JavaScript port produces the same size as the WebAssembly codec at every level and
+takes 1.0 to 1.8× its time, the gap closing at the higher levels; the full 28-row table is in
+`benchmarks/results/codecs-results.json`.
+
+Every fflate row is beaten by a zlib row: by the host's `CompressionStream` at fflate's levels 6
+to 9, by the WebAssembly codec below. Above ratio 3.361 fflate has no setting, while the
+WebAssembly codec reaches 3.429. fflate's level 6 sits between zlib's levels 5 and 6 on ratio,
+which is why its output is larger than zip.js's in the library tables.
 
 Decompression of the same stream:
 
 | Codec | Time | Throughput |
 |---|--:|--:|
-| WASM zlib | **46 ms** | 434.7 MB/s |
-| `DecompressionStream` | 56 ms | 354.6 MB/s |
-| pure-JS zlib | 110 ms | 181.5 MB/s |
-| fflate | 123 ms | 162.7 MB/s |
+| WASM zlib | **54 ms** | 369.5 MB/s |
+| `DecompressionStream` | 57 ms | 352.6 MB/s |
+| pure-JS zlib | 111 ms | 180.6 MB/s |
+| fflate | 128 ms | 156.0 MB/s |
 
-The WASM inflate is 2.7× faster than fflate's, and faster than Node's own
-`DecompressionStream`, since the Chromium `inffast_chunk` port landed in 2.11.0.
+The WebAssembly inflate and Node's `DecompressionStream` are within 6 % of each other; fflate's
+inflate takes 2.4× the time of the WebAssembly one, the pure-JavaScript port 2.1×.
 
-## Decompression
+Alone, the WebAssembly backend deflates at level 6 in 1.46× the time of `CompressionStream` for
+0.7 % more bytes and inflates within 6 % of `DecompressionStream`. zip.js uses it by itself
+when no `CompressionStream` exists or when a level other than the default is requested;
+`useCompressionStream: false` selects it on every host, for an output that does not depend on
+the host's zlib.
 
-Level-6 archives, read back and fully materialized. archiver has no unzip API, so it is
-excluded.
+### Concurrent `add()` and the backends
 
-| Workload | @zip.js/zip.js | jszip | fflate |
+8 files × 8 MB of text, 64 MB in one Node process (`benchmarks/bench-backends.js`), without
+Web Workers unless noted. `add()` calls can be issued concurrently, and the table shows what
+that buys with each backend.
+
+| Configuration | Median time | Output | vs jszip |
 |---|--:|--:|--:|
-| Compressible text (20 MB) | **66 ms** | 133 ms | 117 ms |
-| 5,000 files × ~2 KB | 603 ms | 445 ms | **104 ms** |
+| **zip.js — `CompressionStream`, concurrent `add()`** | **676 ms** | 19.6 MB | **8.6×** |
+| fflate — async (its own worker pool) | 768 ms | 20.0 MB | 7.5× |
+| archiver — Node zlib | 2324 ms | 19.6 MB | 2.5× |
+| zip.js — `CompressionStream`, sequential `add()` | 2421 ms | 19.6 MB | 2.4× |
+| fflate — `zipSync` (single thread) | 3165 ms | 20.0 MB | 1.8× |
+| zip.js — WASM zlib, sequential `add()` | 3553 ms | 19.7 MB | 1.6× |
+| zip.js — WASM zlib, concurrent `add()` | 3577 ms | 19.7 MB | 1.6× |
+| zip.js — pure-JS zlib, concurrent `add()` | 3954 ms | 19.7 MB | 1.5× |
+| zip.js — pure-JS zlib, sequential `add()` | 4008 ms | 19.7 MB | 1.4× |
+| jszip (pako, single thread) | 5788 ms | 19.7 MB | 1.0× |
+
+With the host's `CompressionStream`, zip.js goes from 2421 ms with sequential `add()` calls to
+676 ms with concurrent ones, 3.6×, without Web Workers: Node runs `CompressionStream` off the
+main thread, so the entries compress on several cores while the JavaScript thread only feeds
+them. fflate's async API, which runs its own worker pool, takes 768 ms on the same input; its
+output is 2 % larger than the zlib rows, so it does slightly less work. The WebAssembly and
+pure-JavaScript backends run on the main thread, and concurrent `add()` changes nothing for them.
+
+Requesting a non-default level, e.g. `{ level: 5 }`, selects the bundled codec instead of
+`CompressionStream`, which has no level control, and gives up this parallelism unless
+`useWebWorkers` is set. The [Compression levels](#compression-levels) table shows what a lower
+level buys on each runtime.
+
+## Node, Bun and Deno
+
+The same zip.js code under the three runtimes, in-process, median of 3
+(`benchmarks/bench-runtimes.js`). Browsers were not measured for these tables.
+
+### Concurrent `add()` per runtime
+
+Concurrent `add()` spreads across cores only where the runtime runs `CompressionStream` off the
+JavaScript thread. Same 8 × 8 MB workload as the backends table, level 6. That table spawns one
+process per run and this one measures in-process after a warmup, which is why their Node numbers
+differ:
+
+| Runtime | sequential `add()` | concurrent `add()` | concurrent `add()`, `chunkSize` 256 KB | concurrent `add()` + `useWebWorkers` |
+|---|--:|--:|--:|--:|
+| Node.js v26.7.0 | 2.25 s | **0.59 s** | 0.59 s | 0.59 s |
+| Bun 1.4.2 | 1.19 s | 1.19 s | **0.24 s** | 0.25 s |
+| Deno 2.9.6 | 1.31 s | 1.31 s | 1.33 s | **0.34 s** |
+
+- **Node** runs `CompressionStream` off the JavaScript thread, on the libuv threadpool, four
+  threads by default (`UV_THREADPOOL_SIZE`): concurrent `add()` alone is 3.8× faster than
+  sequential, and the chunk size changes nothing. Node has no `Worker` global, so
+  `useWebWorkers` spawns nothing there and the entries run in-process, in the same time.
+- **Bun** runs `CompressionStream` off the JavaScript thread only for writes larger than 128 KB
+  (its native implementation, since Bun 1.4 in August 2026). zip.js writes 64 KB chunks by
+  default, so concurrent `add()` alone gains nothing on Bun; `chunkSize: 256 * 1024` makes it
+  4.9× faster, and `useWebWorkers: true` 4.7×.
+- **Deno** runs `CompressionStream` on the JavaScript thread whatever the write size: concurrent
+  `add()` alone gains nothing, `useWebWorkers: true` is 3.9× faster.
+
+### Compression levels
+
+Level 6 runs the host's `CompressionStream`, every other level the bundled WebAssembly zlib, so
+whether a lower level buys speed depends on how fast the host's zlib is. The pure-JavaScript
+column runs the same JavaScript on each engine. One 20 MB text entry, one thread:
+
+| Runtime | level 6, `CompressionStream` | level 5, WASM zlib | level 5, pure-JS zlib | level 1, WASM zlib |
+|---|--:|--:|--:|--:|
+| Node.js v26.7.0 | 686 ms / 6.12 MB | 521 ms / 6.56 MB | 780 ms / 6.56 MB | 192 ms / 7.53 MB |
+| Bun 1.4.2 | 371 ms / 6.20 MB | 464 ms / 6.56 MB | 665 ms / 6.56 MB | 168 ms / 7.53 MB |
+| Deno 2.9.6 | 403 ms / 6.21 MB | 590 ms / 6.56 MB | 689 ms / 6.56 MB | 228 ms / 7.53 MB |
 
-zip.js has the fastest large-stream decompression. On thousands of tiny entries the
-per-entry setup cost dominates and **fflate is dramatically faster and lighter** — again
-the right tool when you are unpacking many small files.
+On Node, level 5 on the WebAssembly codec is 24 % faster than the default for 7 % more bytes.
+On Bun and Deno the default is already faster than level 5, so level 5 there is slower and
+larger; only level 1 buys speed on them, 55 % on Bun and 44 % on Deno, at 21 % more bytes. The
+pure-JavaScript port at level 5 takes 1.5× the WebAssembly time on Node, 1.4× on Bun and 1.2×
+on Deno, and is slower than the default on every runtime. The two bundled codecs produce the
+same size on every runtime; the level-6 sizes differ because they come from three different
+zlib builds.
 
-## Encryption — AES-256, stored entry
+### One 256 MB stream
+
+On bulk data zip.js adds almost nothing over the host's `CompressionStream`, so its throughput is
+that of the zlib the runtime ships, and they differ. One 256 MB text file, one thread, in
+memory, fed in 64 KB writes as zip.js does; gzip is Apple's, timed as a child process:
+
+| Runtime | `CompressionStream` alone | zip.js, one entry | Output |
+|---|--:|--:|--:|
+| Node.js v26.7.0 | 8.99 s | 8.78 s | 78.3 MB |
+| Bun 1.4.2 | 4.73 s | 4.77 s | 79.4 MB |
+| Deno 2.9.6 | 5.13 s | 5.23 s | 79.5 MB |
+| Apple `gzip -6`, classic zlib | 12.3 to 12.4 s | | 78.9 MB |
+
+zip.js is within 2 % of the raw stream on every runtime. On this file Bun's `CompressionStream`
+takes 53 % of Node's time and Deno's 57 %, for about 1.5 % more bytes; Apple's gzip takes 1.4×
+Node's time. Which zlib each runtime ships is not verified here; the table measures the result.
+
+## Encryption: AES-256 on a stored entry
 
 An AES entry pays the cipher on every byte, so this section measures the engines zip.js can run
-the WinZip cipher on (AES-CTR with the Gladman counter, HMAC-SHA1) against the sjcl code they
-replaced after 2.13.1. The entry is stored (level 0) so no codec sits in the pipeline, and the
-"before" row is the 2.13.1 bundle measured by the same script. 20 MB of incompressible data,
-in-process, single thread, median of 5; the two numbers are one archive written, then read back.
+the WinZip cipher on (AES-CTR with the counter WinZip specifies, HMAC-SHA1) against the sjcl code
+they replaced after 2.13.1. The entry is stored (level 0) so no codec sits in the pipeline, and
+the "before" row is the 2.13.1 bundle measured by the same script. 20 MB of incompressible data,
+in-process, single thread, median of 5 (`benchmarks/bench-aes.js`); the two numbers of a cell are
+one archive written, then read back.
 
 | Engine | Node.js | Bun | Deno |
 |---|--:|--:|--:|
-| WebAssembly, linked into the module of the WebAssembly builds | **111 / 111 MB/s** | **115 / 115** | 99 / 100 |
-| JavaScript, the fallback of those builds and the engine of the native and core builds | 91 / 86 | 102 / 102 | **109 / 103** |
-| 2.13.1, sjcl | 26 / 25 | 29 / 29 | 19 / 19 |
+| WebAssembly, linked into the module of the WebAssembly builds | **131 / 130 MB/s** | **118 / 121** | 123 / 122 |
+| JavaScript, the fallback of those builds and the engine of the native and core builds | 114 / 114 | 112 / 111 | **142 / 129** |
+| 2.13.1, sjcl | 25 / 25 | 27 / 27 | 19 / 19 |
 
-The same entry at 32 MB in a browser, through the Web Worker pool, median of 3 passes
-([`benchmarks/bench-aes.html`](benchmarks/bench-aes.html)):
+The same measurement in a browser, through the Web Worker pool, on 32 MB of bytes generated in
+the page (the corpus is not served to the browser), median of 3 passes
+([`benchmarks/bench-aes.html`](benchmarks/bench-aes.html), which prints its result and writes no
+file):
 
 | Engine | Firefox 154 | Chrome 153 |
 |---|--:|--:|
-| WebAssembly | **87 / 89 MB/s** | **99 / 101** |
-| JavaScript | 55 / 59 | 77 / 77 |
+| WebAssembly | **96 / 101 MB/s** | **118 / 121** |
+| JavaScript | 68 / 69 | 100 / 98 |
 | 2.13.1, sjcl | 17 / 17 | 22 / 22 |
 
-What to take from it:
-
-- **The JavaScript engine alone is 3.5× sjcl on Node and 3 to 4× in browsers.** sjcl ran the
-  cipher 16 bytes at a time through a generic bit-array layer; the new engine works on typed
-  arrays and is fed whole chunks. Every build has it.
-- **The WebAssembly kernel is the same code in C, and it is flat across hosts: 100 to 115 MB/s
-  everywhere.** What varies is the JavaScript engine, within 20 % of the kernel either way on
-  Node, Bun and Deno, whose JITs run typed-array code about as fast as wasm, and 1.3 to 1.6×
-  slower in browsers (Safari 26.6, measured at the engine level only, sits with Chrome at 1.3×).
-  The WebAssembly builds use the kernel whenever their module loads and fall back to the
-  JavaScript engine when it cannot, for instance under a Content Security Policy without
-  `'wasm-unsafe-eval'`, which is why the fallback stays in the bundle.
-- **Neither is hardware AES, and nothing in a browser can be.** OpenSSL on this machine encrypts
-  AES-256-CTR at 5.8 GB/s with the ARMv8 instructions and at 245 MB/s with them disabled
-  (`OPENSSL_armcap=0`). WebAssembly has no access to them, and Web Crypto cannot run this counter
-  mode: it increments the last byte where WinZip increments the first, and it offers no ECB to
-  build the keystream from. Software AES in the 100 to 120 MB/s range is the ceiling until a
-  platform API exposes the instructions.
-- The kernel costs the default bundle 2.1 KB gzipped; the native and core builds carry only the
-  JavaScript engine and grew by 0.1 KB.
-
-## Streaming a large file — 256 MB, disk → zip → disk
-
-The input is streamed from disk and the archive is streamed back to disk; neither is
-ever fully held in memory (for the libraries that support it).
-
-| Library | Median time | Peak memory (Δ) | Output |
-|---|--:|--:|--:|
-| zip.js (workers) | **8888 ms** | 60 MB | 78.3 MB |
-| archiver | 9150 ms | 71 MB | 78.3 MB |
-| zip.js (1 thread) | 9296 ms | 62 MB | 78.3 MB |
-| fflate | 12549 ms | **43 MB** | 80.2 MB |
-| jszip | 22014 ms | 484 MB | 78.9 MB |
-
-zip.js, fflate and archiver all hold memory **flat** while streaming — zip.js peaks ~60 MB
-over baseline regardless of the 256 MB input, thanks to real backpressure through the
-compression pipeline. **jszip buffers the entire file** and needs ~484 MB, at more than
-twice the wall-clock time. If you process files that do not fit comfortably in memory,
-avoid jszip.
-
-## Against native tooling — 7-Zip
-
-How far is zip.js from a native archiver? [`benchmarks/bench-7z.js`](benchmarks/bench-7z.js)
-compares it against the `7zz` CLI (7-Zip 25.01), disk-to-disk on both sides, under Deno
-2.9.6. 7-Zip timings include process spawn (~ms).
-
-**No 7-Zip preset runs zlib's algorithm**, so `-mx=6` and level 6 are not the same request
-and a table pairing them by digit is measuring two things at once. This section therefore
-has two parts: the defaults against each other, and then a frontier that varies *one* axis,
-the compression level, on **both** sides at a fixed core budget.
-
-### Defaults against defaults
-
-Level 6 and `-mx=6`, i.e. what each tool does when you do not tune it. Every contender the
-harness measures is listed; time / output size.
-
-| Workload (compress) | zip.js (1 thread) | zip.js (workers) | 7-Zip (1 thread) | 7-Zip `-mx=6` (mt) | 7-Zip `-mx=1` (mt) |
-|---|--:|--:|--:|--:|--:|
-| Compressible text (20 MB) | **418 ms** / 6.2 MB | 428 ms / 6.2 MB | — | 2540 ms / 5.8 MB | 444 ms / 6.8 MB |
-| Incompressible data (20 MB) | **321 ms** / 21.0 MB | 333 ms / 21.0 MB | — | 418 ms / 21.0 MB | 353 ms / 21.0 MB |
-| 8 files × 8 MB | 1308 ms / 19.9 MB | 308 ms / 19.9 MB | 8102 ms / 18.4 MB | 1510 ms / 18.4 MB | **294 ms** / 21.7 MB |
-| 5,000 files × ~2 KB | 1245 ms / 5.2 MB | 825 ms / 5.2 MB | 580 ms / 4.9 MB | 193 ms / 4.9 MB | **173 ms** / 5.0 MB |
-| Large file, disk-to-disk (256 MB) | **5.4 s** / 79.5 MB | 5.5 s / 79.5 MB | — | 33.4 s / 73.6 MB | 5.8 s / 86.7 MB |
-
-| Workload (decompress) | zip.js (1 thread) | zip.js (workers) | 7-Zip (1 thread) | 7-Zip (mt) |
-|---|--:|--:|--:|--:|
-| Compressible text (20 MB) | 83 ms | **61 ms** | — | 81 ms |
-| 8 files × 8 MB | 181 ms | **83 ms** | 241 ms | 247 ms |
-| 5,000 files × ~2 KB | 989 ms | 906 ms | 491 ms | **462 ms** |
-
-`7-Zip (1 thread)` is only listed where it means something: a single file is one deflate
-stream, so `-mmt` changes nothing there and the two 7-Zip columns would measure the same
-run. That is also why zip.js's worker pool does nothing on the single-file rows — the
-parallelism both tools have is *between* entries, never inside one.
-
-### The frontier — one axis, both sides
-
-Levels 1–9 on the zip.js side against `-mx=1,3,5,6,7,9` on the 7-Zip side, sorted by output
-size. A tool is faster than another only where it is faster **at the same size**, and
-`frontier` marks a row that nothing smaller beats on time.
-
-**One thread, one deflate stream on both sides** — 20 MB of text:
-
-| Encoder | Output | Ratio | Time | |
-|---|--:|--:|--:|---|
-| 7-Zip `-mx=9` | 5.7 MB | 3.665 | 14889 ms | frontier |
-| 7-Zip `-mx=7` | 5.7 MB | 3.665 | 6643 ms | frontier |
-| 7-Zip `-mx=5` | 5.8 MB | 3.646 | 2597 ms | frontier |
-| 7-Zip `-mx=6` | 5.8 MB | 3.646 | 2605 ms | |
-| zip.js level 8 | 6.1 MB | 3.429 | 1537 ms | frontier |
-| zip.js level 9 | 6.1 MB | 3.429 | 1544 ms | |
-| zip.js level 7 | 6.1 MB | 3.421 | 1305 ms | frontier |
-| **zip.js level 6 (default)** | 6.2 MB | 3.377 | **418 ms** | frontier |
-| zip.js level 5 | 6.6 MB | 3.196 | 590 ms | |
-| 7-Zip `-mx=1` | 6.8 MB | 3.096 | 458 ms | |
-| 7-Zip `-mx=3` | 6.8 MB | 3.096 | 453 ms | |
-| zip.js level 4 | 6.9 MB | 3.036 | 358 ms | frontier |
-| zip.js level 3 | 7.0 MB | 2.975 | 420 ms | |
-| zip.js level 2 | 7.4 MB | 2.850 | 266 ms | frontier |
-| zip.js level 1 | 7.5 MB | 2.785 | 239 ms | frontier |
-
-**The same 20 MB, one thread, but on Node** — because the zip.js side of that table is not
-one codec. Level 6 is the host's `CompressionStream`, so it changes with the runtime; every
-other level is the bundled WASM codec, which does not (its output is byte-identical on both
-and its times agree within 5 %):
-
-| Encoder | Output | Ratio | Time | |
-|---|--:|--:|--:|---|
-| 7-Zip `-mx=9` | 5.7 MB | 3.665 | 14904 ms | frontier |
-| 7-Zip `-mx=7` | 5.7 MB | 3.665 | 6548 ms | frontier |
-| 7-Zip `-mx=5` | 5.8 MB | 3.646 | 2535 ms | frontier |
-| 7-Zip `-mx=6` | 5.8 MB | 3.646 | 2553 ms | |
-| zip.js level 8 | 6.1 MB | 3.429 | 1474 ms | frontier |
-| zip.js level 9 | 6.1 MB | 3.429 | 1476 ms | |
-| **zip.js level 6 (default)** | 6.1 MB | 3.426 | **696 ms** | frontier |
-| zip.js level 7 | 6.1 MB | 3.421 | 1238 ms | |
-| zip.js level 5 | 6.6 MB | 3.196 | 514 ms | frontier |
-| 7-Zip `-mx=1` | 6.8 MB | 3.096 | 447 ms | frontier |
-| 7-Zip `-mx=3` | 6.8 MB | 3.096 | 445 ms | frontier |
-| zip.js level 4 | 6.9 MB | 3.036 | 304 ms | frontier |
-| zip.js level 3 | 7.0 MB | 2.975 | 375 ms | |
-| zip.js level 2 | 7.4 MB | 2.850 | 221 ms | frontier |
-| zip.js level 1 | 7.5 MB | 2.785 | 200 ms | frontier |
-
-**Every core, both sides** — 8 files × 8 MB, on Deno. It has to be Deno: Node exposes no
-global `Worker`, so `useWebWorkers` cannot spawn one there and only the default level —
-which rides the platform threadpool instead — parallelizes at all. Measured on Node the
-same table reads 617 ms at level 6 against 4090 ms at level 7, i.e. the WASM levels run
-serially, which would make it a comparison of 7-Zip on 8 cores against zip.js on 1.
-
-| Encoder | Output | Ratio | Time | |
-|---|--:|--:|--:|---|
-| 7-Zip `-mx=9` | 18.3 MB | 3.660 | 8625 ms | frontier |
-| 7-Zip `-mx=7` | 18.3 MB | 3.660 | 3796 ms | frontier |
-| 7-Zip `-mx=5` | 18.4 MB | 3.645 | 1510 ms | frontier |
-| 7-Zip `-mx=6` | 18.4 MB | 3.645 | 1540 ms | |
-| zip.js level 9 | 19.6 MB | 3.428 | 971 ms | frontier |
-| zip.js level 8 | 19.6 MB | 3.428 | 991 ms | |
-| zip.js level 7 | 19.6 MB | 3.420 | 852 ms | frontier |
-| **zip.js level 6 (default)** | 19.9 MB | 3.376 | **317 ms** | frontier |
-| zip.js level 5 | 21.0 MB | 3.196 | 405 ms | |
-| 7-Zip `-mx=3` | 21.7 MB | 3.096 | 309 ms | frontier |
-| 7-Zip `-mx=1` | 21.7 MB | 3.096 | 313 ms | |
-| zip.js level 4 | 22.1 MB | 3.037 | 287 ms | frontier |
-| zip.js level 3 | 22.6 MB | 2.975 | 316 ms | |
-| zip.js level 2 | 23.6 MB | 2.849 | 239 ms | frontier |
-| zip.js level 1 | 24.1 MB | 2.784 | 218 ms | frontier |
-
-What the two curves say:
-
-- **zip.js's default is a spike on its own curve, because it is a different codec.** The
-  platform's `CompressionStream` exposes no level control, so **level 6 runs the host's
-  native zlib and every other level drops onto the bundled WASM one**. How big the spike is
-  therefore depends on whose zlib the host ships: 418 ms at ratio 3.377 on Deno's zlib-ng,
-  696 ms at 3.426 on Node's Chromium zlib — ~1.7× faster and ~1.4 % looser.
-- **So whether a lower level buys anything is runtime-dependent, and on Deno it does not.**
-  On Node, `level: 5` costs 514 ms against the default's 696 ms: the ordinary trade, 26 %
-  faster for 7 % more bytes. On Deno the default is already 418 ms, so the same `level: 5`
-  takes 590 ms and produces a *larger* archive — **slower and bigger, strictly worse**. If
-  you reach for a lower level to go faster, measure it on your runtime first.
-- **One level is a bad deal everywhere: `level: 3` loses to `level: 4`** on both time and
-  size (375 ms / 7.0 MB against 304 ms / 6.9 MB on Node; 420 ms against 358 ms on Deno).
-  Both are the same WASM codec, so this one is zlib's own curve, not a fallback artifact.
-- **7-Zip's nine presets are three encoders.** `-mx=1` and `-mx=3` are identical, so are
-  `-mx=5`/`-mx=6` and `-mx=7`/`-mx=9` — **`-mx=9` costs 2.3× the time of `-mx=7` for
-  byte-identical output**. The 5.7× jump from `-mx=3` to `-mx=5` is greedy matching giving
-  way to optimal parsing, and threads cannot hide it.
-- **Against the greedy tier zip.js wins outright.** Single-threaded it is 418 ms / 6.2 MB
-  against 453–458 ms / 6.8 MB: faster *and* 9 % smaller than both `-mx=1` and `-mx=3`. On
-  all cores it ties them on time (317 ms against 309 ms) and is still 8 % smaller.
-- **Against the optimal-parsing tier it has nothing**, at any level. 7-Zip's cheapest route
-  to 3.6 costs 1510 ms where zip.js's best is 971 ms at 3.43; buying that last 6 % of ratio
-  costs 4.8× the default's time. That is a real limit of DEFLATE-as-zlib-writes-it, not a
-  tuning gap.
-- **Threading buys the two sides different amounts**: 4.2× for zip.js on 8 × 8 MB
-  (1308 → 308 ms) against 5.4× for 7-Zip (8102 → 1510 ms). zip.js closes most of that gap
-  because it starts from a much faster single-threaded number.
-- **7-Zip legitimately dominates many small files** (~4× on compress, ~2× on decompress):
-  its per-entry cost is near zero, while zip.js pays per-entry orchestration. Same lesson
-  as the fflate rows above — tiny-entry workloads are zip.js's cost center, and the codec
-  is irrelevant there. Note the reverse on 8 × 8 MB decompression, where entries are large
-  enough for the pool to pay off: 83 ms against 247 ms, zip.js ~3× faster.
-
-## The runtime's zlib decides zip.js throughput
-
-On bulk data zip.js is a thin wrapper around the platform's `CompressionStream` — it
-adds ~7 % over the raw encoder on the 256 MB stream. That means throughput is decided
-by **which zlib the runtime vendors**, and they differ a lot. Same 256 MB compressible
-file, one thread, level-6-class output everywhere. This is the one table on this page
-still carrying its July 2026 measurement: it compares runtimes to each other rather than
-zip.js to anything, so it ages with their zlib and not with ours.
-
-| Encoder | Time | Output |
-|---|--:|--:|
-| zlib-ng — Deno & Bun `CompressionStream` | **4.8–5.1 s** | 79.4 MB |
-| Chromium zlib — Node `CompressionStream` / `node:zlib` | 8.9 s | 78.3 MB |
-| classic zlib — Apple `gzip -6` | 12.5 s | 78.9 MB |
-| (reference) 7-Zip `-mx=6` | 33.5 s | 73.6 MB |
-
-Verified in the runtimes' sources: Deno builds `flate2` with vendored
-**zlib-ng** (`__vendored_zlib_ng` default feature), Bun vendors **zlib-ng 2.3.3**
-(SIMD CRC/adler/match kernels, NEON on arm64) behind `node:zlib` and
-`CompressionStream`, and Node vendors **Chromium's zlib fork** (SIMD checksums and
-hash sliding, but a match finder much closer to classic zlib).
-
-Consequences worth knowing:
-
-- **The same zip.js code runs ~1.75× faster on Deno/Bun than on Node** for bulk
-  compression. A "zip.js is fast/slow" measurement is often really a statement about
-  the host's zlib — and the Node tables above are the *pessimistic* end.
-- **The WASM backend is a fallback, but a much closer one since 2.11.0.** It used to be
-  classic zlib plus WebAssembly overhead, ~3× slower than native on compress. It now
-  carries Chromium's zlib: on the codec table above it deflates at level 6 in 1023 ms
-  against the native `CompressionStream`'s 692 ms — 1.5× slower for 0.7 % more bytes — and
-  it *inflates faster* than the native `DecompressionStream` (46 ms against 56 ms). Reach
-  for it when no native `CompressionStream` exists, when you need a specific level, or
-  when you need output that does not vary with the host's zlib.
-- Output sizes across the zlib family are interchangeable (78–79 MB): it is one
-  algorithm at four levels of implementation tuning. zip.js inherits whichever the
-  host provides — including future upgrades, for free.
-
-## When to pick which
-
-- **Choose zip.js** for the fastest compression of large or multiple entries
-  (parallelism with no Web Workers), the fastest large-stream decompression, flat
-  low-memory streaming of huge files, and the broadest ZIP feature set in one library —
-  AES & ZipCrypto encryption, Zip64, split/multi-volume archives, and an optional Web
-  Worker pool.
-- **Choose fflate** for archives of thousands of tiny entries, and when you want the
-  smallest memory footprint and the smallest bundle. Note what it does *not* buy you: at
-  equal output size its codec is not the fastest one here (see
-  [Codecs](#codecs-compared-at-equal-output-size)), so the win is fflate's very low
-  per-entry cost, not its deflate.
-- **archiver** is a solid streaming compressor on Node but cannot read archives.
-- **jszip** is convenient but the slowest here and buffers whole files in memory.
+- The JavaScript engine is 4.0 to 4.6× sjcl on Node, Bun and in the two browsers, and 6.8 to
+  7.5× on Deno, where sjcl was slowest. sjcl ran the cipher 16 bytes
+  at a time through a bit-array layer; the new engine works on typed arrays and is fed whole
+  chunks, with the AES rounds and the SHA-1 steps written out. Every build has it.
+- The WebAssembly kernel is the same C code on every host, with the same rounds written out:
+  118 to 131 MB/s on Node, Bun and Deno, 96 to 121 MB/s in the two browsers. The JavaScript
+  engine is within 13 % of it on Node and Bun, ahead of it on Deno, and 1.2 to 1.4× slower in
+  the browsers. The WebAssembly builds use
+  the kernel whenever their module loads and fall back to the JavaScript engine when it cannot,
+  for instance under a Content Security Policy that does not allow WebAssembly
+  (`'wasm-unsafe-eval'`).
+- Neither is hardware AES. OpenSSL on this machine (`openssl speed -evp aes-256-ctr`, 8 KB
+  blocks) runs AES-256-CTR at 9.4 GB/s with the ARMv8 AES instructions and at
+  249 MB/s with them disabled (`OPENSSL_armcap=0`). WebAssembly has no access to those
+  instructions, and Web Crypto cannot run this counter mode: it increments the last byte of the
+  counter where WinZip increments the first, and it exposes no ECB to build the keystream from.
+- The bundles did not grow with the new engines. Gzipped, `dist/zip.min.js` went from 67,869
+  bytes in 2.13.1 to 67,820 in 2.14.0, `dist/zip-native.min.js` from 73,798 to 72,060 and
+  `dist/zip-core.min.js` from 36,405 to 35,493 (`git show <tag>:<file> | gzip -9 | wc -c`):
+  sjcl's removal outweighs the JavaScript engine and the kernel. Writing the rounds out after
+  2.14.0 gives some of it back: 71,238, 73,339 and 36,235 bytes for the three files behind the
+  encryption tables above.
 
 ## Reproduce
 
-The harness lives in [`benchmarks/`](benchmarks/). It has no ties to the machine above;
-run it on yours.
+The harness lives in [`benchmarks/`](benchmarks/). `bench.js` and `bench-backends.js` need macOS
+(`/usr/bin/time -l` for peak memory) and Node; the other scripts run wherever zip.js runs.
 
 ```sh
 cd benchmarks
-npm install            # jszip, fflate, archiver (zip.js is used from the repo)
-npm run corpus         # generate the deterministic datasets under .corpus/
-node bench.js          # the head-to-head tables (compress / decompress / disk streaming)
-node bench-backends.js # the parallelism & codec-backend matrix
-node bench-codecs.js   # the codecs alone, sorted by output size
-node bench-aes.js      # the AES engines on a stored entry (also: bun / deno run -A); bench-aes.html is the browser page
-deno run -A bench-7z.js # zip.js vs the 7zz CLI (also: bun bench-7z.js)
+npm install              # jszip, fflate, archiver (zip.js is used from the repository)
+npm run corpus           # generate the datasets under .corpus/
+node bench.js            # the head-to-head tables: compress, decompress, disk streaming
+node bench-backends.js   # the concurrent add() and backends table
+node bench-codecs.js     # the codecs alone, sorted by output size
+node bench-aes.js        # the AES engines; also: bun bench-aes.js, deno run -A bench-aes.js
+node bench-runtimes.js   # the runtime tables; also: bun bench-runtimes.js, deno run -A bench-runtimes.js
 ```
 
-`bench-7z.js` needs the 7-Zip CLI (`brew install sevenzip`) and runs under Deno or Bun;
-set `ZIPJS_BACKEND=wasm` to measure the WebAssembly codec instead of the native
-`CompressionStream`, and `SKIP_HUGE=1` to skip the 256 MB combo.
-
-Both scripts write JSON and a human-readable log to `benchmarks/results/`. Set
-`RUNS=<n>` to change the number of repetitions (default 3). The datasets are generated
-from a seeded PRNG (`benchmarks/lib/corpus.js`), so every run — and every library —
-sees identical bytes.
+Each script writes its JSON to `benchmarks/results/`; the `*-run.log` files there are the
+console output of the runs behind this page. `RUNS=<n>` sets the number of repetitions (default
+3, 5 in `bench-aes.js`). `ZIPJS_BUNDLE=<path to a previous index.min.js> node bench-aes.js` adds
+the row of a previous release; `git show v2.13.1:index.min.js` gave the sjcl row. The browser
+encryption table comes from `benchmarks/bench-aes.html`, served from the repository root
+(`npx http-server -p 8080`, then `http://localhost:8080/benchmarks/bench-aes.html`), with
+`?engine=js` for the JavaScript engine and `?bundle=zipjs-2.13.1.min.js` for a bundle copied next
+to the page; it prints the median of its three passes and a JSON line.
+
+Two more scripts feed no table on this page: `bench-crc.js` compares the two ways zip.js can
+obtain the CRC-32 of an entry compressed by `CompressionStream`, and `bench-7z.js` compares
+zip.js with the 7-Zip command line (`brew install sevenzip`, runs under Deno or Bun).