WebAssembly and native C++ are not two implementations of the same decision. WASM is a distribution and isolation choice that carries a performance ceiling; native C++ is a performance choice that carries a distribution cost. Teams that compare them as if they were interchangeable performance targets — pick whichever the team can staff — usually end up paying for a port whose gain the browser sandbox was never going to deliver.
The comparison is still worth running. It just has to be run against the same profiled bottleneck, with the deployment constraints separated out first.
What does comparing WASM to C++ for browser-side inference mean in practice?
It means producing two numbers for one workload, not one number for two languages.
The workload is the specific stage the profiling pass identified as owning the latency budget. If you have not attributed the budget across model compute, host-language overhead, and IO, there is nothing to compare yet — the comparison inherits its meaning from that attribution. We treat that as a precondition, not a step you can fold into the port.
Given a profiled bottleneck, an honest comparison pass yields, for each candidate target:
- measured per-request latency at the concurrency the client actually sees;
- peak memory during inference, against the sandbox’s own limit;
- the delivered payload size over the wire — model weights plus runtime;
- first-inference cold-start time, including runtime instantiation and warm-up;
- the browser and device coverage the option actually holds.
Those five figures are what make a browser-side port decision defensible rather than preferential. Latency alone is not, because on the browser the two targets are not competing on latency in the first place.
Which constraints force a WASM target rather than making it a performance choice?
Three, and they are all distribution constraints:
- No native install. The code has to arrive over HTTP and run in a page. That removes native C++ from the client entirely — not because it is slower, but because it cannot be delivered there.
- Sandboxed memory and no direct device access. WASM runs in a linear memory space with no CUDA, no arbitrary driver access, and threading only via cross-origin-isolated
SharedArrayBuffer. GPU compute is reachable only through WebGPU or WebGL, which is a different runtime story from a native CUDA build. - Single-origin delivery and data residency. When input data must not leave the device — clinical imagery, on-device document capture, camera frames under a privacy constraint — the browser is the compute surface by policy, and no server-side latency win changes that.
If none of those three applies, WASM is not being forced on you, and a native C++ or CUDA service behind a network call is very likely the cheaper answer. That inversion is the single most useful outcome of the pass, and it is the one teams skip.
The comparison matrix
Read this as a constraint map, not a scoreboard. The right column is not “the fast option” — it is the option that stops being available the moment constraint 1 or 3 above holds.
| Axis | WASM in the browser | Native C++/CUDA behind a service call |
|---|---|---|
| What decides it | Deployment surface (no install, sandbox, data residency) | Performance and unit cost per request |
| Compute ceiling | Sandboxed CPU with SIMD; GPU only via WebGPU/WebGL | Full native SIMD, CUDA, TensorRT, kernel-level tuning |
| Parallelism | Threads only under cross-origin isolation; worker-scoped | Full thread and multi-GPU control |
| Memory | Linear memory, browser-imposed cap, no host paging control | Host RAM plus device memory, explicitly managed |
| Cold start | Fetch + instantiate + weight load on first inference | Warm process; cold start is a server concern, amortised |
| Payload cost | Model plus runtime shipped to every client | Nothing shipped; request/response only |
| Variance | Across browsers, devices, and thermal states | Across your own fleet, which you control |
| Fails when | Model compute dominates the profiled budget | Round trip, data residency, or offline use is unacceptable |
What ceiling should you expect from WASM?
WASM vs C Browser comes into focus here. What we would ask a team to produce before committing engineering is a four-way build set against one profiled bottleneck: WASM with SIMD and threads off, WASM with SIMD on, WASM with SIMD and threads on, and a native reference build of the same kernel on the same machine. The native build is not a deployment candidate — it is the ruler. It tells you how much of the achievable compute you are giving up for delivery, which is the actual price of the sandbox.
Two things to hold steady while measuring. First, SIMD and threads are not defaults: wasm-simd needs to be enabled in the toolchain (Emscripten, or the SIMD-enabled builds of ONNX Runtime Web and TensorFlow.js), and threads need the cross-origin isolation headers served correctly. A WASM number measured without them is a floor, not a ceiling, and we see that mistake reported as “WASM is 8× slower” more often than any other. Second, browser variance is part of the result. One browser on one laptop is a sample, not a measurement; a mobile Safari figure and a thermally-throttled Android figure belong in the same table as the desktop Chrome figure.
The general shape holds regardless of the numbers you get: WASM narrows the gap to native CPU code considerably once SIMD is on, and does nothing at all about the absence of CUDA. If the profiled bottleneck is dense model compute that a native build would hand to a GPU, the browser target does not have a path to your latency figure. That is the case where the honest output of the comparison is “not in the browser” — and the arithmetic behind that conclusion is the same arithmetic we set out in when a Python-to-C++ port moves cost without moving the bottleneck, applied to a different destination.
What the WASM path costs after launch
The port’s ledger does not close at the merge. Bundle size is a recurring cost paid by every visitor: the runtime and the weights are shipped, and quantising the model to shrink the download changes accuracy, which pulls the accuracy check back into scope. Cold start is paid on first inference per session and is the figure users perceive as “slow,” independent of steady-state latency. Browser coverage is a support surface — every combination you claim, you test. And the WASM build is a second implementation whose toolchain (Emscripten versions, target features, the runtime’s own release cadence) drifts separately from the Python or native path you kept for training.
We work through the porting decision itself, including where the browser branch sits inside it, in when porting Python inference to C++ or WASM actually pays off. The profiling discipline this comparison depends on is the same one behind the rest of our GPU and inference performance work, and the browser-target branch of the port-decision step is where it lands in the Inference Cost-Cut Pack.
Where this leaves us: the interesting question is rarely “WASM or C++.” It is whether the constraint pushing you into the browser is real, and whether the profiled bottleneck survives contact with a sandbox that has no GPU. Answer those two and the language argument mostly dissolves.
Frequently Asked Questions
What does comparing WASM to C++ for browser-side inference mean in practice? A useful WASM vs C Browser clarification is this. It means measuring the same profiled bottleneck under both targets and producing five figures per candidate: per-request latency, peak memory, delivered payload size, first-inference cold-start time, and browser/device coverage. A single latency number from one browser is not a comparison. The pass is only meaningful if a profiling attribution has already established which stage owns the latency budget.
Which constraints force a WASM target rather than making it a performance choice? No native install on the client, the browser’s sandboxed memory and lack of direct device access, and data-residency or offline requirements that keep input on the device. When any of those holds, native C++ on the client is unavailable rather than merely slower. When none holds, a native service behind a network call is usually the cheaper answer.
How do we benchmark WASM fairly? Build four variants against one bottleneck — SIMD off, SIMD on, SIMD plus threads, and a native reference build as the ruler — and confirm the toolchain actually emitted SIMD and that cross-origin isolation headers are serving correctly for threads. Include at least one mobile and one thermally-constrained device, since browser and device variance is part of the result rather than noise around it.
What does the WASM path cost after launch? Bundle size is paid by every visitor, cold start is paid per session on first inference, every claimed browser/device combination becomes a test surface, and the WASM build is a second implementation with its own toolchain drift. Quantising to shrink the download pulls accuracy validation back into scope, so the shrink is not free either.
The WASM vs C Browser takeaway
WASM vs C Browser is rarely the hard part — knowing which of its failure modes you can live with is. That answer is workload-specific, and it is worth writing down before you build.
