Frank Denis has rerun his libsodium WebAssembly benchmark for 2026, testing the same C crypto code against runtimes released in June 2024, 2025, and 2026. The goal is boring and useful: are runtimes actually improving, not just on one flashy microbenchmark but on a real cryptographic workload.
**What was tested**
WebAssembly (WASM) is a portable binary format that lets compiled C or Rust code run in a sandboxed environment. A "runtime" is the engine that executes a .wasm module — similar in role to V8 for JavaScript, but purpose-built for WASM. libsodium is a widely used cryptography library; its benchmark suite covers arithmetic-heavy operations where instruction-set support matters.
Denis compiled libsodium to WebAssembly with four feature levels: baseline (no extras), lime1, lime1+simd128, and lime1+simd128+wide_arithmetic, then ran each against native x86-64 code on an AMD Ryzen AI 9 HX 470. Results are expressed as slowdown relative to native: 2.0× means "twice as slow." Lower is better.
**Year-over-year results**
Wasmtime improved every year: 2.67× native in 2024, 2.54× in 2025, 2.41× in 2026. Node also improved slowly, from 8.60× to 7.95×. Wazero was basically flat at roughly 4.7–4.8×. WAMR in AOT mode was already near-native in 2025 and stayed there at 1.57–1.59×. Wasmer regressed in the 2025 release before recovering in 2026. Bun's 2026 result was about three times faster than its 2025 result, though it still trails Node on this workload. WAVM produced the fastest 2026 baseline, but no fair 2024 or 2025 comparison exists.
This chart illustrates the year-over-year improvement trajectory discussed in the results section, showing how the fastest runtime changed across releases.
The baseline chart provides the foundational comparison data, illustrating how each engine's no-extras performance evolved year over year.
**Feature variants matter more than the runtime brand**
For 2026 releases, adding wide_arithmetic was the single biggest change:
- Wasmtime 46.0.0: 2.41× → 1.46× native - Wasmer 7.1.0: 2.08× → 1.33× native
Only Wasmtime and Wasmer could run the full wide_arithmetic build among stable releases tested; WAMR rejected it with an unsupported-opcode error. lime1 and simd128 alone showed inconsistent effects, sometimes helping, sometimes hurting, sometimes lost in noise.
This breakdown explains why feature selection mattered more than runtime brand, showing which engines supported the wide_arithmetic instruction set that delivered the biggest gains.
**Failures and caveats**
Not all runs completed. Bun 1.2.17 failed one benchmark in baseline; Node 22.3.0 failed several Argon2 and Scrypt tests until given an explicit 64 MiB linear-memory cap — a V8 memory-mode threshold, not a simple "more memory helps" setting. WAMR 2.1.0 (the 2024 slot) could not AOT-compile these modules at all. Very small benchmarks with three iterations are noisy. These results are specific to libsodium-style crypto on one machine; real-world workloads may differ.
**Bottom line**
For CPU-heavy cryptography in WebAssembly, runtime choice still matters a lot. The spread between the best complete 2026 result (Wasmer with wide_arithmetic at 1.33× native) and the worst (Bun baseline at 8.77× native) is large. Feature support — especially wide_arithmetic — can shift a runtime from "pretty good" to "surprisingly close to native." The mainstream runtimes are not standing still, but WebAssembly performance is not one number; it depends on the runtime, its release, enabled features, and the workload.
The ranking captures the article's central finding about the large performance spread between the best and worst 2026 results across different runtimes.