WebAssembly runtimes in 2026: who got faster

Seven WebAssembly runtimes in 2026 show clear speed shifts for libsodium crypto workloads.

This comparison shows which runtimes actually sped up from 2024 to 2026, using the same libsodium benchmark and a native baseline.

Item	2024	2025	2026
Wasmtime	2.67x native	2.54x native	2.41x native
Node	8.60x native	7.95x native	7.95x native
WAMR	n/a	1.59x native	1.57x native
wasm2c	2.83x native	2.66x native	2.49x native
WasmEdge	2.20x native	2.02x native	1.74x native
Wasmer	2.30x native	2.37x native	2.08x native
Bun	12.45x native	26.03x native	8.77x native

1. Wasmtime

Wasmtime is the cleanest example of steady improvement. In the baseline build, it went from 2.67x native in 2024 to 2.41x native in 2026, with each yearly release shaving off a little more time. That is not a dramatic jump, but it is the kind of trend that matters when you run the same code every day.

Its bigger story is feature support. On the 2026 release, the wide_arithmetic build dropped Wasmtime from 2.41x native to 1.46x native. For libsodium-style arithmetic, that is a meaningful shift toward native-like performance.

• Baseline: 2.41x native in 2026
• With wide_arithmetic: 1.46x native
• Best fit: crypto code that can use newer Wasm instructions

2. Wasmer

Wasmer had a mixed baseline history, but the 2026 release matters because it finally benefits strongly from wide_arithmetic. The plain build was 2.08x native, which is solid but not special compared with the best runtimes in this test.

Once wide_arithmetic is enabled, Wasmer drops to 1.33x native, which makes it the fastest complete current-year result in this benchmark set. That is a large enough gain to change deployment choices for CPU-heavy crypto work.

• Baseline: 2.08x native in 2026
• With wide_arithmetic: 1.33x native
• Notable point: feature support matters more than baseline alone

3. WAMR

WAMR is the quiet speed story. In AOT mode, the 2025 and 2026 releases stayed around 1.6x native, which is very strong for portable WebAssembly. The 2024 slot could not be fully compared because the AOT compiler rejected these modules.

The catch is feature coverage. WAMR handled the baseline and the SIMD-lime variants, but it rejected wide_arithmetic with an unsupported opcode. If your code needs the newest arithmetic instructions, WAMR is not the runtime to bet on yet.

• 2025 baseline: 1.59x native
• 2026 baseline: 1.57x native
• Limit: no wide_arithmetic support in this test

4. WasmEdge

WasmEdge improved enough to matter, but the benchmark also shows why command-line defaults can distort results. An early 2026 run accidentally used interpreter mode and looked terrible; switching to AOT mode fixed that and brought the runtime back into a strong position.

With AOT enabled, its 2026 baseline landed at 1.74x native, better than its earlier releases in this test. That puts WasmEdge in the fast camp for this workload, especially if you control the execution mode.

• 2024 baseline: 2.20x native
• 2025 baseline: 2.02x native
• 2026 baseline in AOT mode: 1.74x native

5. wasm2c

wasm2c is the pragmatic choice if you are willing to translate Wasm to C ahead of time and compile that C for the host. It does not chase runtime tricks, but it keeps improving modestly and remains one of the better options in this benchmark family.

Its 2026 baseline was 2.49x native, a small but real improvement over prior years. The appeal here is deployment simplicity: if your build system already likes native compilation, wasm2c fits that model well.

wasm2c -> C -> zig cc -O3 -march=native

6. Node

Node improved slowly, which is better than stagnation. The baseline result moved from 8.60x native in 2024 to 7.95x native in 2025 and stayed near that level in 2026. That is still far behind the faster runtimes, but the direction is at least positive.

Node also exposed a practical memory issue during the benchmark. Some libsodium tests failed until the Wasm module was given an explicit maximum linear memory. In other words, raw speed is only part of the story; runtime behavior around memory can decide whether the workload finishes at all.

• 2024 baseline: 8.60x native
• 2026 baseline: about 7.95x native
• Watch for: explicit linear memory settings

7. Bun

Bun is the most dramatic year-over-year change in the set. Its 2024 and 2025 results were far behind the pack, but the 2026 release cut that gap sharply and landed at 8.77x native in the baseline test. That is still slower than Node here, but the improvement is too large to dismiss.

For this benchmark, Bun is the runtime that moved from “hard to recommend for this workload” toward “worth retesting on your own code.” If your team already uses Bun, the 2026 numbers justify another look.

• 2024 baseline: 12.45x native
• 2025 baseline: 26.03x native
• 2026 baseline: 8.77x native

How to decide

If you want the fastest result for crypto-heavy Wasm in 2026, start with Wasmer and Wasmtime, then check whether your code can use wide_arithmetic. Those two runtimes get the biggest payoff from the newer instructions, and the gains are large enough to change the ranking.

If you need portability or ahead-of-time translation, WAMR, WasmEdge, and wasm2c are the next group to test. Node and Bun are improving, but for this workload they still trail the dedicated runtimes. The main lesson is simple: benchmark your real module, because feature support and execution mode can matter as much as the runtime name.