Practice WebAssembly performance vocabulary: offloading to WASM for speedup, Web Workers for off-main-thread computation, SIMD instructions, binary size, and WASM vs. JS benchmarking.
0 / 5 completed
1 / 5
'We moved the image processing to WASM for 5× speedup.' Why does WASM often outperform JavaScript for compute-intensive tasks?
WASM's performance advantage over JavaScript comes from: (1) AOT compilation — WASM arrives as already-compiled bytecode, not source code requiring JIT; (2) static typing — no runtime type checks; (3) predictable memory model — no garbage collection pauses; (4) ability to express low-level optimisations. For CPU-bound tasks (image processing, cryptography, physics, codecs), WASM can be 2-10× faster than equivalent JS.
2 / 5
'The computation runs off the main thread in a Worker.' Why is off-main-thread execution important for WASM?
The browser's main thread handles both JavaScript execution and rendering. A long-running WASM computation on the main thread blocks rendering — users see a frozen, unresponsive UI. Moving WASM to a Web Worker runs it on a separate thread, keeping the main thread free to handle user input and rendering. Data is passed between the worker and main thread via postMessage or SharedArrayBuffer.
3 / 5
'SIMD instructions accelerate the vector operations.' What is SIMD in the context of WASM?
WASM SIMD (WebAssembly SIMD proposal, now standardised) exposes CPU vector instructions to WASM code. Instead of processing one pixel at a time, SIMD operations can process 4 or 16 values in one instruction — providing 4-16× throughput for data-parallel operations like image filters, audio processing, ML inference, and physics simulations. It's a major performance win for compute-heavy WASM applications.
4 / 5
'The WASM binary is 200KB gzipped.' Why does WASM binary size matter for web applications?
WASM binary size is a critical web performance metric. A 200KB gzipped binary must be: downloaded (network time), decompressed, and compiled by the browser (which is fast but proportional to size). Large binaries (multi-MB) can significantly delay page load. Optimisation techniques include: wasm-opt (Binaryen optimiser), tree shaking unused code, stripping debug information, and using wasm-pack's release profile.
5 / 5
When comparing 'WASM vs. JS vs. native performance', in what scenarios does WASM typically NOT outperform JavaScript?
WASM's performance advantage is strongest for CPU-bound numerical computation. For tasks involving frequent JS-WASM boundary crossings (DOM manipulation, string processing) the overhead can erase the benefit. JavaScript engines are extremely optimised for string operations and DOM interaction. WASM is also not faster than JS for I/O-bound operations (network, storage) since both are equally limited by browser APIs.