WebAssembly for performance

Would WebAssembly brighten Asha's photo sooner?

Asha is writing a review of Mint tea. She adds a photo she took in the shop. The shop was dim, so the photo came out dark.

Meera wants a Brighten button. One tap, and the photo gets lighter before it uploads. Ravi writes it in JavaScript. It adds 40 to the red, green and blue of every pixel.

Asha's photo is big. Her phone's camera takes 12 megapixels: 12 million pixels. Each pixel is 4 bytes, so Brighten has 48 million numbers to look at.

Ravi has heard that WebAssembly is faster than JavaScript. So he asks a question. If he rewrote brighten() in WebAssembly, would Asha see her brighter photo sooner? Or not?

The JavaScript lesson JavaScript & WebAssembly showed what WebAssembly is. Here is the short version. WebAssembly, or Wasm, is code in a compact binary format. Browsers run it next to JavaScript. You write it in another language, and a compiler turns it into a .wasm file.

Ravi wrote two Wasm versions. One is plain. The other uses SIMD: a way to change 16 bytes in one step. The course timed all three on Asha's phone. Here is when her brighter photo appeared:

1// When Asha's brighter photo reached her screen, in ms after her tap.2const taps = [3  { way: "JavaScript", shown: 147.5 },4  { way: "WebAssembly", shown: 209.9 },5  { way: "WebAssembly with SIMD", shown: 106.7 },6];7for (const tap of taps) console.log(`${tap.way}: ${tap.shown} ms`);

• Line 1 is a comment. Times are in milliseconds (ms). A millisecond is a thousandth of a second.
• Lines 3 to 5 hold the three versions. shown is how long after her tap the brighter photo reached her screen.
• Line 7 prints JavaScript: 147.5 ms, WebAssembly: 209.9 ms and WebAssembly with SIMD: 106.7 ms.

Here is what Asha saw. These are real frames Chrome captured. A frame is one picture the browser draws on the screen.

So the answer is: it depends. Plain WebAssembly made Asha wait longer, 209.9 ms against 147.5 ms. The version with SIMD was quicker, at 106.7 ms.

Even with SIMD, the tap took nearly three quarters of JavaScript's time. Why it matters: Wasm doesn't make every job faster. You have to measure your own work, the whole tap and not just the loop.

This lesson measures each part, in five steps:

1. Which work gets faster, and at which sizes.
2. What a .wasm file costs to load.
3. What it costs to cross between JavaScript and Wasm.
4. SIMD and threads, which do more work per step.
5. WasmGC and JSPI, two newer features.

How the course recorded it

• Two pages: Asha's review page, in three versions, and a lab page that timed each part on its own. A local server sent them over HTTPS.
• Asha's phone: this computer in Chrome 157, with its processor, the CPU, slowed 4 times.
• The Wasm: Ravi wrote it in AssemblyScript, a language that looks like TypeScript. The course built it with AssemblyScript's compiler, version 0.28.20.
• Loads: each version loaded three times, taking turns. The lesson quotes the middle one. Each time, Chrome kept a trace: a detailed record of everything it did, with screenshots.
• Taps: Asha's tap is a mouse press and release sent through Chrome's DevTools protocol. Chrome passes it straight to the page.

Which work gets faster in WebAssembly

First, the two brighten() functions side by side. Here is Ravi's JavaScript:

1// brighten.js: adds 40 to each pixel's red, green and blue.2function brighten(pixels) {3  for (let i = 0; i < pixels.length; i += 4) {4    pixels[i] += 40; // red: a Uint8ClampedArray stops at 2555    pixels[i + 1] += 40; // green6    pixels[i + 2] += 40; // blue7  }8}

• Line 2 takes pixels, a Uint8ClampedArray. That's a list of bytes that stops at 255 instead of wrapping around. The page gets one from the canvas that shows the photo. It holds red, green, blue and alpha for each pixel, one after another. Alpha is how see-through the pixel is.
• Line 3 walks the list 4 bytes at a time: one pixel per step.
• Lines 4 to 6 add 40 to red, green and blue. Alpha stays as it is.

And here is the same loop in AssemblyScript:

1// brighten.ts: adds 40 to each pixel's red, green and blue.2export function brighten(start: usize, end: usize): void {3  for (let i = start; i < end; i += 4) {4    store<u8>(i, min<u32>(<u32>load<u8>(i) + 40, 255));5    store<u8>(i + 1, min<u32>(<u32>load<u8>(i + 1) + 40, 255));6    store<u8>(i + 2, min<u32>(<u32>load<u8>(i + 2) + 40, 255));7  }8}9 10// One value at a time, for the page to call once per value.11export function liftOne(value: u32): u32 {12  return min<u32>(value + 40, 255);13}

• Line 2 takes two numbers, start and end. They are places in Wasm's memory, not a list. The function can't take a JavaScript array, so the photo has to sit in Wasm's memory.
• Line 3 walks from start to end, 4 bytes at a time.
• Line 4 reads one byte with load<u8>(i). <u32> makes it a bigger number, so 250 + 40 can reach 290. min() then stops it at 255, and store<u8>() writes it back.
• Lines 5 and 6 do the same for green and blue.
• Lines 11 to 13 are liftOne(), the same sum for one value. You'll use it later.

The course built it with npx asc brighten.ts -O3 -o brighten.wasm. The finished file, brighten.wasm, is 193 bytes. Here is how the page uses it:

1// brighten.js: brightens Asha's photo with brighten.wasm.2const wasm = WebAssembly.instantiateStreaming(fetch("brighten.wasm"));3 4document.querySelector("#brighten").addEventListener("click", async () => {5  const { memory, brighten } = (await wasm).instance.exports;6  const pixels = photo.data;7  if (memory.buffer.byteLength < pixels.length) memory.grow(Math.ceil(pixels.length / 65536));8  const bytes = new Uint8Array(memory.buffer, 0, pixels.length);9  bytes.set(pixels); // copy the photo into Wasm's memory10  brighten(0, pixels.length);11  pixels.set(bytes); // copy it back12  context.putImageData(photo, 0, 0);13});

• Line 2 starts loading brighten.wasm as soon as the page runs. The next section looks at instantiateStreaming().
• Line 5 takes two of its exports, the things a module offers to JavaScript. memory is Wasm's linear memory: one long row of bytes. brighten is the function.
• Line 7 makes the memory big enough for the photo. Wasm memory grows in pages of 65,536 bytes.
• Line 8 makes a view: a Uint8Array laid over Wasm's memory, so JavaScript can write into it.
• Line 9 copies the photo in. Line 10 brightens it. Line 11 copies it back out.
• Line 12 draws the photo on the canvas. Every version does this.

The camera photo, timed on its own

The lab page timed the same work without the page around it. Each way ran in a fresh page. Its first run was its very first call. Then it ran again, and the lab kept the middle of those later runs.

1// The camera photo (48 MB) on Asha's phone, copies included. Times in ms.2const first = { js: 102.4, wasm: 162.9, simd: 60.7 };3const later = { js: 95.4, wasm: 54.5, simd: 15.4 };4for (const way of ["js", "wasm", "simd"]) {5  console.log(`${way}: first ${first[way]} ms, later ${later[way]} ms`);6}

• Line 2 holds each way's first run. Line 3 holds its later runs. Both include the copies.
• Lines 4 to 6 print js: first 102.4 ms, later 95.4 ms, then wasm: first 162.9 ms, later 54.5 ms, then simd: first 60.7 ms, later 15.4 ms.

The picture holds three findings.

Later runs, Wasm wins. Plain Wasm took 54.5 ms, a little over half of JavaScript's 95.4 ms. With SIMD it took 15.4 ms. Why it matters: work that repeats, like a preview under a slider, gets real gains.

The first run is different. Plain Wasm's first run took 162.9 ms. The brightening alone took 133.9 ms of that. Its later runs did the same brightening in 44.2 ms. So why was the first run three times slower?

Chrome's engine, V8, has two compilers for Wasm. You met them in the JavaScript lesson. Liftoff makes machine code very quickly, but the code is simple. TurboFan takes longer and makes faster code. V8's docs say it compiles each function with Liftoff the first time it is called. If the function runs a lot, TurboFan compiles it again in the background.

But a call that started on Liftoff's code finishes on it. Asha's tap was one long call. So all 12 million pixels ran on Liftoff's code. JavaScript's engine can move a running loop to faster code. Lesson Tiered compilation called that on-stack replacement. That's why JavaScript's first run, 102.4 ms, was close to its later ones.

Why it matters: a one-off job, like Asha's single tap, pays the first-run price. Time the first run, not only warm ones.

Small photos don't care. Here is a 200 by 150 thumbnail:

1// A 200 x 150 thumbnail, later runs, copies included. Times in ms.2const later = { js: 0.24, wasm: 0.14, simd: 0.04 };3console.log(`Slowest: ${Math.max(...Object.values(later))} ms`);

• Line 2 holds the later runs of each way.
• Line 3 prints the slowest: Slowest: 0.24 ms.

A frame lasts about 16.7 ms on a 60 Hz screen. A quarter of a millisecond is invisible. Why it matters: for small inputs, the simplest code wins. Like one cup, wash it by hand.

Read the table across. Each row is one version, for the camera photo on Asha's phone:

Pick a size to see every way. The second way comes up again in Crossing between JavaScript and Wasm:

What kind of work is this?

Brighten fits Wasm well for three reasons:

• It is one loop that runs millions of times.
• It only does maths on numbers: bytes in, bytes out.
• It never touches the page while it runs.

Surma, from Chrome's team, put it this way: "In general, JavaScript and WebAssembly can achieve the same peak performance." JavaScript only gets there on its engine's "fast path". Wasm's gain, he wrote, is "predictable performance". In his experience, he wrote, most performance problems on the web come from layout and paint. Wasm can't help with those.

Some jobs the browser already does in its own fast code. Google Sheets once ran regular expressions with a library compiled to Wasm. Switching to the browser's own RegExp made them nearly 100 times faster. Why it matters: if the browser has a built-in way, try it before you ship a module.

What a Wasm file costs to load

Ravi's module is tiny: 193 bytes. That's shorter than this paragraph. But real Wasm is often big, because it brings a whole library written in C, C++ or Rust.

Meera's next wish: make the photo's file smaller before it uploads. Squoosh, Google's image app, does this with MozJPEG, a JPEG encoder written in C. An encoder turns pixels into an image file. Squoosh ships MozJPEG as Wasm.

The course loaded that same encoder, from the jSquash package. Its .wasm file is 251,524 bytes. Compressed with brotli, it is 49,581 bytes on the network. With gzip, it would be 59,822.

There are two ways to load it:

1// Two ways to load a module: while it streams, or after it has all arrived.2const streamed = await WebAssembly.compileStreaming(fetch("mozjpeg_enc.wasm"));3 4const response = await fetch("mozjpeg_enc.wasm");5const bytes = await response.arrayBuffer(); // wait for every byte6const compiled = await WebAssembly.compile(bytes);

• Line 2 passes the fetch() straight to compileStreaming(). It starts compiling while bytes are still arriving. That's streaming compilation.
• Lines 4 to 6 wait for every byte first, with arrayBuffer(). Only then does compile() start.

instantiateStreaming(), on the page, works the same way and also makes the instance. MDN calls it "the most efficient, optimized way to load Wasm code." The server must label the file application/wasm, or streaming refuses it.

The course loaded MozJPEG's module both ways, on Slow 4G and Asha's phone:

1// MozJPEG's module on Slow 4G, on Asha's phone. Times in ms after fetch().2const streamed = { lastByte: 849.3, ready: 851.6 };3const downloadedFirst = { lastByte: 850.5, ready: 853.3 };4console.log(`Streamed: ready ${streamed.ready} ms`);5console.log(`Downloaded first: ready ${downloadedFirst.ready} ms`);

• Lines 2 and 3 hold, for each way, when the last byte arrived and when the module was ready.
• Lines 4 and 5 print Streamed: ready 851.6 ms and Downloaded first: ready 853.3 ms.

Almost the same. The streamed module was ready 2.3 ms after its last byte. Downloaded first, compiling took 1.6 ms. Why so little? V8's docs say it doesn't compile any functions at first. Each one is compiled the first time it's called. Why it matters: on a slow network, the download is the cost. Keep the file small, send it compressed, and start it early.

So where did the compiling go? Into the first encode:

1// Encoding Asha's 1600 x 1067 photo as a JPEG. Times in ms.2const firstVisit = { firstEncode: 479.5, secondEncode: 441 };3const repeatVisit = { ready: 6.1, firstEncode: 477.9 };4console.log(`First visit: ${firstVisit.firstEncode} ms, then ${firstVisit.secondEncode} ms`);5console.log(`Repeat visit: ready after ${repeatVisit.ready} ms, first encode ${repeatVisit.firstEncode} ms`);

• Line 2 holds the first visit's first and second encode of Asha's photo.
• Line 3 holds a repeat visit: when the module was ready, and its first encode.
• Lines 4 and 5 print First visit: 479.5 ms, then 441 ms and Repeat visit: ready after 6.1 ms, first encode 477.9 ms.

Chrome's trace shows what happened. During the first encode, V8 compiled 82 functions with Liftoff, each the first time it ran. That took 15.2 ms on the main thread. TurboFan compiled the 20 busiest again, in the background. So the second encode was 38.6 ms quicker.

On the repeat visit, the file came from the HTTP cache, the browser's store of files from earlier visits. No bytes crossed the network, and the module was ready after 6.1 ms. But the first encode was as slow as before.

Chrome can also keep compiled Wasm in a code cache. V8's docs set three conditions. The module must come from a streaming method. Only TurboFan's code is kept. And it is kept only once there is enough of it, so "small WebAssembly modules ... may never get cached."

In the course's recording, Chrome never wrote that cache for this module. The trace has no cache event. Every repeat visit compiled all 82 functions again. Why it matters: count on the HTTP cache to save the download. Don't count on the code cache.

Pick a visit to see all its numbers:

Crossing between JavaScript and Wasm

Every time JavaScript calls into Wasm, it crosses a line. The place where the two hand values to each other is called the boundary. Numbers cross it easily. A photo can't be read across it: Wasm only reads bytes in its own memory.

Ravi's first try didn't move the photo at all. It called Wasm once for every value:

1// One call into Wasm for every red, green and blue value.2function brightenByCalls(pixels, liftOne) {3  for (let i = 0; i < pixels.length; i += 4) {4    pixels[i] = liftOne(pixels[i]);5    pixels[i + 1] = liftOne(pixels[i + 1]);6    pixels[i + 2] = liftOne(pixels[i + 2]);7  }8}

• Line 2 takes the pixels and liftOne, the export from brighten.wasm.
• Lines 4 to 6 call it for red, green and blue: three calls for every pixel.

The lab page timed it on the camera photo:

1// The camera photo again: one call per value, or one call for all. Times in ms.2const calls = 36_000_000; // red, green and blue for 12 million pixels3const perValue = 2608.8;4const oneCall = 54.5;5console.log(`One call per value: ${perValue} ms, about ${Math.round((perValue / calls) * 1e6)} ns a call`);6console.log(`One call: ${oneCall} ms`);

• Line 2 counts the calls: 36 million.
• Lines 3 and 4 hold the two times, from later runs.
• Line 5 prints One call per value: 2608.8 ms, about 72 ns a call. A nanosecond (ns) is a millionth of a millisecond. Line 6 prints One call: 54.5 ms.

72 ns is tiny. But 36 million of them add up to 2,608.8 ms. That's 27 times slower than plain JavaScript. Why it matters: call Wasm for a big job, not once per item.

One call is the tray. But the tray has to be loaded. Look back at the page's code: line 9 copies the photo into Wasm's memory, and line 11 copies it back. Here is what that cost with SIMD:

1// Wasm with SIMD on the camera photo, later runs. Times in ms.2const run = { copyIn: 4.8, work: 5.8, copyOut: 5.1 };3const copies = Math.round((run.copyIn + run.copyOut) * 10) / 10;4console.log(`Copying: ${copies} ms. Brightening: ${run.work} ms.`);

• Line 2 holds a later run's three parts.
• Line 3 adds the two copies, and rounds to a tenth.
• Line 4 prints Copying: 9.9 ms. Brightening: 5.8 ms.

With SIMD, moving the photo took longer than brightening it. In the lab, the very first copy into newly grown memory took 25.0 ms. Why it matters: once the loop is fast, copies are the next cost. Keep big data on the Wasm side.

How? Load the photo into Wasm's memory once, when Asha picks it. An ImageData can be built on a view of that memory. Then putImageData() draws straight from it, and no tap has to copy the photo in or out.

Now try it in your own browser. This lab brightens a made-up photo with the course's own .wasm files:

SIMD and threads: more work per step

SIMD stands for Single Instruction, Multiple Data. It is one step that changes many values at once. Wasm's SIMD works on 128 bits at a time: 16 bytes, or four of Asha's pixels.

1// brighten-simd.ts: the same, 16 bytes (four pixels) at a time.2// 40 for red, green and blue, 0 for alpha, four times over.3const lift = i8x16(40, 40, 40, 0, 40, 40, 40, 0, 40, 40, 40, 0, 40, 40, 40, 0);4 5export function brightenSimd(start: usize, end: usize): void {6  for (let i = start; i < end; i += 16) {7    v128.store(i, i8x16.add_sat_u(v128.load(i), lift));8  }9}

• Line 3 makes lift: 16 bytes in one value. Each pixel gets 40 for red, green and blue, and 0 for alpha.
• Line 6 walks memory 16 bytes at a time.
• Line 7 does everything. v128.load(i) reads 16 bytes at once. i8x16.add_sat_u adds each byte to the matching byte of lift. "sat" means it stops at 255 instead of wrapping around. v128.store writes all 16 back.

In later runs on the camera photo, the SIMD loop took 5.8 ms. JavaScript's took 95.4 ms. That's 16 times faster, from one line.

Two builds, and a check

SIMD has to be turned on when you build:

1npx asc brighten.ts -O3 -o brighten.wasm2npx asc brighten-simd.ts -O3 --enable simd -o brighten-simd.wasm

• Line 1 builds the plain version.
• Line 2 builds the SIMD version, with --enable simd. Without it, the compiler stops with "Feature 'simd' is not enabled."

A browser without SIMD rejects the whole SIMD module, not just one function. V8's SIMD guide says to build both versions, then check which one the browser can run:

1// Which build can this browser run? Ask it to check the bytes first.2const simdBytes = await (await fetch("brighten-simd.wasm")).arrayBuffer();3const { instance } = WebAssembly.validate(simdBytes)4  ? await WebAssembly.instantiate(simdBytes)5  : await WebAssembly.instantiateStreaming(fetch("brighten.wasm"));

• Line 2 fetches the SIMD build's bytes.
• Line 3 asks WebAssembly.validate() whether they make a module this browser understands. It checks the bytes without running them.
• Line 4 uses those bytes if the answer is yes. Line 5 loads the plain build if it isn't.

In Chrome 157, the lab page's checks said yes to SIMD, threads, WasmGC and JSPI.

Threads: more hands on one photo

SIMD does more per step. Threads do steps side by side, on more of the processor's cores. A core is one part of the CPU that runs one thread at a time.

Lesson 27.4 moved work into a worker, a second thread. Wasm threads are workers that share one block of Wasm memory. web.dev lists the parts: workers, a shared WebAssembly.Memory, and atomic operations that let threads take turns safely.

The shared build needs a few more flags:

npx asc brighten-simd.ts -O3 --enable simd,threads --importMemory --sharedMemory --maximumMemory 1024 -o brighten-simd-shared.wasm

--enable threads turns threads on. --importMemory and --sharedMemory make the module use a shared memory that the page hands it. Here is the page:

1// One shared photo, four workers, a quarter each.2const module = await WebAssembly.compileStreaming(fetch("brighten-simd-shared.wasm"));3const memory = new WebAssembly.Memory({ initial: 733, maximum: 1024, shared: true });4const workers = [0, 1, 2, 3].map(() => new Worker("brighten-worker.js"));5workers.forEach((worker) => worker.postMessage({ module, memory }));6const quarter = 48_000_000 / 4;7workers.forEach((worker, i) => worker.postMessage({ fn: "brightenSimd", start: i * quarter, end: (i + 1) * quarter }));

• Line 2 compiles the module once, on the page.
• Line 3 makes a shared memory: 733 pages, room for the 48 MB photo. shared: true makes it a SharedArrayBuffer underneath.
• Line 4 starts four workers.
• Line 5 posts the module and the memory to each one. The page fetches and compiles the module once, and every worker reuses it. web.dev recommends this.
• Lines 6 and 7 give each worker a quarter of the bytes.

1// brighten-worker.js: brightens its own band of the shared photo.2let exports;3onmessage = async ({ data }) => {4  if (data.module) {5    exports = (await WebAssembly.instantiate(data.module, { env: { memory: data.memory } })).exports;6    postMessage("ready");7  } else {8    const start = performance.now();9    exports[data.fn](data.start, data.end);10    postMessage(performance.now() - start);11  }12};

• Line 5 makes an instance from the module it was sent, using the shared memory.
• Line 9 brightens its own band, from start to end. Line 10 sends back how long that took.

Lesson 27.4 showed that DevTools can't slow a worker. So this test ran at this computer's full speed, on its 8 cores, without SIMD:

1// The camera photo, brightened by workers sharing its memory (no SIMD).2// This computer's full speed: DevTools can't slow a worker. Times in ms.3const workers = { one: 10.7, four: 2.8 };4console.log(`Four workers took ${(workers.four / workers.one * 100).toFixed(0)}% of one worker's time.`);

• Line 3 holds later runs with one worker and with four.
• Line 4 prints Four workers took 26% of one worker's time.

One worker's first run took 29.9 ms, against 10.7 ms later. That's Liftoff again. With SIMD, the job was already so short that threads saved under a millisecond: 1.41 ms on the main thread, 0.66 ms with four workers.

Why it matters: threads pay for big work on phones with several cores. But they need a cross-origin isolated page, as lesson 27.4 showed. And each worker costs time to start.

WasmGC and JSPI: other languages, and waiting

Two newer features help whole apps move to Wasm. Neither makes Asha's brighten() faster. They change what is worth moving.

WasmGC: the browser cleans up

Languages like Java, Kotlin and Dart use a garbage collector: a helper that frees objects nobody uses any more. Plain Wasm has only bytes, so those languages had to pack their own collector into the .wasm file. WasmGC lets Wasm keep its objects in the browser's own collector instead. It's like a visiting chef using the café's bins, instead of bringing his own.

That makes files smaller. V8's article gives one small test program as an example. Built with WasmGC, it was 2.3 KB. Built from C or Rust, it was 6.1 to 9.6 KB, because those bring their own memory code.

And it can make apps faster. Google Sheets' calculation engine is written in Java. It ran in a worker, compiled to JavaScript. The team moved it to WasmGC. Their first version was about twice as slow as JavaScript. After a lot of tuning, it became about twice as fast. Why it matters: WasmGC is for bringing a whole app written in such a language. Your own JavaScript doesn't change.

JSPI: Wasm that waits for a Promise

Code in C or Rust often expects an answer right away: "read this file". Web APIs like fetch() answer later, with a Promise. JSPI, JavaScript Promise Integration, joins the two. Wasm pauses at a call that returns a Promise. It carries on when the Promise settles. Meanwhile, the page keeps running.

It's like a cook who stops at "wait for the delivery", serves other customers, and picks the recipe up where she left it. Here is a module that needs this week's review count:

1// reviews.ts: needs this week's review count, which the page fetches.2@external("env", "reviewCount")3declare function reviewCount(): i32;4 5export function perTea(teas: i32): i32 {6  return reviewCount() / teas;7}8 9// Asks for the count many times, to time one pause.10export function countMany(times: i32): i32 {11  let total = 0;12  for (let i = 0; i < times; i++) total += reviewCount();13  return total;14}

• Lines 2 and 3 declare an import: a function the page hands the module, called reviewCount.
• Line 6 calls it and divides by the number of teas, as if the answer were already there.
• Lines 10 to 14 call it many times. The lab used this to time one pause.

1const reviewCount = new WebAssembly.Suspending(async () => {2  const response = await fetch("review-count.json");3  return (await response.json()).count;4});5const { instance } = await WebAssembly.instantiateStreaming(fetch("reviews.wasm"), { env: { reviewCount } });6const perTea = WebAssembly.promising(instance.exports.perTea);7console.log(await perTea(40));

• Lines 1 to 4 wrap an async function in WebAssembly.Suspending. When Wasm calls it, Wasm pauses until its Promise settles.
• Line 5 hands it to the module as its import.
• Line 6 wraps the export with WebAssembly.promising(), so calling it returns a Promise.
• Line 7 waits, and prints 100: 4,000 reviews over 40 teas.

The lab page ran it on Asha's phone, with the server holding the count back like a slow API:

1// What the lab page saw on Asha's phone.2const wait = { answer: 100, waitedMs: 303.7, timerRuns: 30 };3const pauseUs = 0.375; // one pause and resume, in microseconds4console.log(`perTea(40) gave ${wait.answer} after ${wait.waitedMs} ms. A 10 ms timer ran ${wait.timerRuns} times meanwhile.`);5console.log(`One pause cost ${pauseUs} µs.`);

• Line 2 holds the answer, the wait, and how often a 10 ms timer ran during it.
• Line 3 holds one pause and resume, in microseconds (µs): thousandths of a millisecond.
• Line 4 prints perTea(40) gave 100 after 303.7 ms. A 10 ms timer ran 30 times meanwhile. Line 5 prints One pause cost 0.375 µs.

The main thread stayed free while Wasm waited. A plain call to the same import cost 0.15 µs, so a pause adds about 0.2 µs. V8's article estimated about 1 µs per call in its own demo. Why it matters: ported code can wait for the network without freezing the page.

Should this run in WebAssembly?

Each job below comes from a real shop page. Sort it by where it belongs:

Common mix-ups

• "WebAssembly is always faster than JavaScript." No. On Asha's first tap, plain Wasm took 209.9 ms and JavaScript took 147.5 ms.
• "A faster loop makes the whole tap that much faster." No. The SIMD loop was 16 times faster, but the tap went from 147.5 ms to 106.7 ms. Copies and drawing stayed.
• "Calling into Wasm is free." No. Each call is tiny, but 36 million of them took 2,608.8 ms.
• "Streaming compilation hides a big download." No. On Slow 4G, both ways were ready after about 850 ms. The download was the cost.
• "Chrome always keeps compiled Wasm for the next visit." No. It keeps only TurboFan's code, and only when there's enough. The recording never saw it happen.
• "WasmGC and JSPI make my JavaScript faster." No. They help code from other languages run and wait in the browser. JavaScript doesn't change.

Practice exercises

Answer first, then use the hints.

// brighten.js: adds 40 to each pixel's red, green and blue.
function brighten(pixels) {
  for (let i = 0; i < pixels.length; i += 4) {
    pixels[i] += 40; // red: a Uint8ClampedArray stops at 255
    pixels[i + 1] += 40; // green
    pixels[i + 2] += 40; // blue
  }
}

const pixels = new Uint8ClampedArray([250, 10, 100, 255]);
brighten(pixels);
console.log(pixels.join(" "));

// One call into Wasm for every red, green and blue value.
function brightenByCalls(pixels, liftOne) {
  for (let i = 0; i < pixels.length; i += 4) {
    pixels[i] = liftOne(pixels[i]);
    pixels[i + 1] = liftOne(pixels[i + 1]);
    pixels[i + 2] = liftOne(pixels[i + 2]);
  }
}

let count = 0;
const liftOne = (value) => {
  count += 1;
  return Math.min(value + 40, 255);
};
brightenByCalls(new Uint8ClampedArray(8), liftOne);
console.log(count);

Check your understanding

For each question, ask what really took the time: the loop, the copies, the calls, or the download.

Key takeaways

• Wasm can speed up a big loop over numbers. Small jobs, page updates and network waits don't get faster.
• A function's first call runs on Liftoff's simple code. Time the first run, not just warm ones.
• A .wasm file costs its download. Chrome compiles each function on first use, so streaming saves little.
• The HTTP cache saves the download on repeat visits. Don't count on the code cache.
• Every call crosses the boundary. Make one big call, and keep big data in Wasm's memory.
• SIMD does 16 bytes per step. Build it twice and check with validate().
• Threads share one memory between workers. They need a cross-origin isolated page.
• WasmGC and JSPI help whole apps in other languages run and wait in the browser.

Sources

The facts on this page come from these specs, docs and source files:

• WebAssembly compilation pipeline, V8.
• AssemblyScript: Using the compiler, AssemblyScript.
• Replacing a hot path in your app's JavaScript with WebAssembly, Surma, Chrome for Developers.
• Google Sheets and WasmGC, web.dev.
• jSquash: Squoosh's codecs for the browser, jamsinclair on GitHub.
• WebAssembly.instantiateStreaming(), MDN.
• V8 release v6.5: streaming compilation, V8.
• Code caching for WebAssembly developers, V8.
• flag-definitions.h, V8 15.7 (Chrome 157), V8 on GitHub.
• Fast, parallel applications with WebAssembly SIMD, V8.
• Using WebAssembly threads from C, C++ and Rust, web.dev.
• WebAssembly performance patterns for web apps, web.dev.
• A new way to bring garbage collected programming languages efficiently to WebAssembly, V8.
• Introducing the WebAssembly JavaScript Promise Integration API, V8.
• JavaScript Promise Integration, Chrome Platform Status.
• Feature status, WebAssembly.org.

Coming next: Fast event handlers. The next module looks at the code that runs when Asha taps, and how to make it answer quickly.