WebAssembly quietly became infrastructure

WebAssembly spent years being described as promising. In 2026 that description is out of date, and the reason is that the interesting deployments stopped being in browsers.

Wasm 3.0 is a W3C standard, WASI Preview 2 is stable, and Figma, Google, Shopify and Adobe run it in production at scale. The number that changed the conversation is the cold start: 1–5 milliseconds, roughly a hundred times faster than a container.

The cold start is the whole argument

Serverless made a specific trade. You stopped paying for idle capacity and accepted that a cold request might take hundreds of milliseconds to a few seconds while a container started. Everyone built around it — provisioned concurrency, keep-warm pings, careful runtime choices — and mostly stopped noticing the workarounds.

At 1–5 milliseconds, the trade disappears. Cold start stops being an architectural concern and becomes an implementation detail, which removes an entire category of workaround from the design.

That is why the edge platforms went this way. Akamai bought Fermyon in 2025 and adopted the Spin framework across more than 4,000 edge locations. Cloudflare Workers, built on Wasm-capable V8 isolates, deployed Llama-3-8b across more than 330 locations in February 2026, reporting 2–4x faster inference with cold starts under 5 milliseconds.

Running a model at the edge is only sensible if starting the runtime is nearly free. It is now.

Why this matters more away from the core

For a user in London or Virginia, the difference between edge and origin is real but modest. For a user several thousand kilometres and a couple of network hops from the nearest region, it is the difference between a responsive product and a sluggish one.

Anyone building for users outside the major cloud regions has spent years choosing between hosting near the users and hosting near the infrastructure. Wasm at the edge weakens that trade-off for a useful class of work: authentication checks, personalisation, request shaping, validation, A/B assignment, and increasingly small-model inference — all things that were previously round trips.

The honest limitations

Enthusiasm is not the same as fit, and Wasm is a poor choice for plenty of things.

The runtime is sandboxed by design, which is the security property and also the constraint. Host access goes through WASI, which is far narrower than a normal OS interface. Anything wanting arbitrary filesystem access, threads or exotic system calls will fight it.

Language support is uneven. Rust, C and C++ compile well. Go works with caveats. Anything with a heavy garbage-collected runtime pays for shipping that runtime.

Performance is around 95% of native for compute-bound work — excellent, and not a reason to rewrite something that is I/O-bound, where the bottleneck was never CPU.

The ecosystem is also younger than the standard's maturity suggests. Debugging and profiling are noticeably less pleasant than in a mainstream runtime, and that shows up as engineering time.

The realistic use today

The strong case is short-lived, compute-bound work that has to happen close to the user and is currently a round trip to origin. That is a narrow description and it covers a lot of real latency.

The other genuinely strong case is untrusted plugin execution. If you run customer-supplied code, a Wasm sandbox is a far better isolation story than a process boundary and considerably cheaper than a container per tenant.

What I would not do is rewrite a working service. Around 5.5% of sites visited by Chrome users touch WebAssembly, which reflects targeted adoption rather than a platform shift. The technology is ready; that does not make it a replacement for a backend that is already fast enough.

The reason to pay attention now is not that Wasm will replace your stack. It is that the cold-start number removes a constraint you have probably been designing around for years without noticing.