Performance of WebAssembly Runtimes in 2026

Author: Frank DENIS (Random Thoughts)
Date: June 23, 2026

The central question driving this analysis is simple: Are WebAssembly (Wasm) runtimes actually getting faster?

This study serves as a longitudinal follow-up to previous libsodium benchmarks conducted in 2019, 2021, and 2023. The goal here isn't to find a "winner" in a single microbenchmark or to admire a polished marketing chart. Instead, I wanted to answer a more practical question: If I take the same C-based cryptographic code, compile it to Wasm, and run it across the latest runtime and its predecessors from one and two years ago, is there a measurable trend of improvement?

To find out, I benchmarked libsodium using runtimes released around June 2024, June 2025, and June 2026.

The TL;DR: Wasmer currently leads in performance, though WAVM, WAMR, and Wasmtime are trailing closely. WAVM stands out for its superior optimizer, which produces highly efficient code from baseline portable Wasm. Additionally, the introduction of wide_arithmetic instructions has proven to be a massive leap forward for cryptographic workloads.

---

🛠️ Methodology: What I Measured

The test suite utilized is libsodium's own benchmark tool, specifically built from commit 8e3be8615ba6adcd7babaecf5e76f516890ba5fb.

Build Variants

I established a native baseline and several Wasm configurations to test the impact of specific CPU features:

• Native x86-64: Compiled via Zig for the local CPU target (using -Dcpu=native).
• Plain WebAssembly: The standard baseline.
• Wasm + lime1: Adding lime1 support.
• Wasm + lime1 + simd128: Adding SIMD capabilities.
• Wasm + lime1 + simd128 + wide_arithmetic: The full feature set.

Runtime Specifics

• wasm2c: The resulting C code was compiled using zig cc -O3 -march=native.
• WAMR: Operated in AOT mode. I used wamrc to convert .wasm to .aot, then executed via iwasm. Since --cpu=native wasn't supported, I used --target=x86_64 --cpu=x86-64-v4 --opt-level=3 to match the host hardware.

Execution Commands

The native build command was: zig build -Denable_benchmarks -Doptimize = ReleaseFast -Dcpu = native -Diterations = 3

The Wasm variants followed a similar pattern, targeting wasm32-wasi with varying CPU strings:

# Plain Wasm
zig build -Denable_benchmarks -Dtarget = wasm32-wasi -Doptimize = ReleaseFast -Diterations = 3

# With lime1
zig build -Denable_benchmarks -Dtarget = wasm32-wasi -Doptimize = ReleaseFast -Dcpu = lime1 -Diterations = 3

# With lime1 and simd128
zig build -Denable_benchmarks -Dtarget = wasm32-wasi -Doptimize = ReleaseFast -Dcpu = lime1+simd128 -Diterations = 3

# Full feature set
zig build -Denable_benchmarks -Dtarget = wasm32-wasi -Doptimize = ReleaseFast -Dcpu = lime1+simd128+wide_arithmetic -Diterations = 3

Environment & Hardware

The results are expressed as the geometric mean of slowdowns relative to native code, calculated as: $\text{Slowdown} = \frac{\text{Wasm Execution Time}}{\text{Native Execution Time}}$ (e.g., a value of $2.0$ indicates the runtime is twice as slow as the native build).

---

📅 Version Matrix

For most runtimes, I selected the stable release from June 2026, June 2025, and June 2024.

Notes on anomalies:

• WAVM: Historical comparison was impossible; older nightlies either collapsed to a 2022 version or failed to run on the test hardware.
• WAMR 2.1.0: While it installed, the AOT compiler crashed with an invalid WASM stack data type error on Zig-generated modules. It remains in the table but lacks aggregate data.

---

📈 Analysis: Baseline WebAssembly

This section examines the plain Wasm build (no lime1, SIMD, or wide arithmetic).

• Wasmtime: Showed consistent, incremental gains.
  • 2024: $2.67\times$ native $\rightarrow$ 2025: $2.54\times$ $\rightarrow$ 2026: $2.41\times$.
• Node: Experienced a slow but steady improvement, moving from $8.60\times$ to $7.95\times$ native.
• WAMR (AOT): Remained consistently fast. It hit $1.59\times$ in 2025 and $1.57\times$ in 2026 (essentially the same within the margin of error).
• Wasmer: Had a strange trajectory. It regressed dipped in 2025 but saw a massive recovery in 2026. The 2026 version is roughly $3\times$ faster than the 2025 version. While still slower than Node in this specific test, the momentum is very positive.
• WasmEdge: Also performs well, though I encountered a configuration pitfall. Initially, the 0.17.0 run used interpreter mode, which was catastrophically slow. Switching to --run-mode=aot corrected this, resulting in a 2026 baseline of $1.74\times$ native.

---

🚀 Optimized Builds & Feature Impact

While baseline tests are great for "apples-to-apples" comparisons, real-world deployment usually involves the fastest supported build. I tested the best possible configuration for each runtime (Baseline $\rightarrow$ lime1 $\rightarrow$ simd128 $\rightarrow$ wide_arithmetic).

The results mirror the baseline trends, but with a critical caveat: Wasmtime and Wasmer see massive performance boosts when wide_arithmetic is enabled.

Performance Hierarchy (2026)

The Feature Story

The evolution of Wasm features is more impactful than the evolution of the runtimes themselves. For the 2026 releases, the aggregate slowdowns shifted significantly based on the enabled features:

• lime1 and simd128: Provide noticeable gains.
• wide_arithmetic: The real "game changer" for crypto-heavy code.

The runtime version is the only thing that matters $\rightarrow$ The combination of the runtime and the supported CPU feature set is what determines performance.