The solution
Loading a big WebAssembly module used to be serial: the browser downloaded the whole file into an ArrayBuffer, handed it to the JavaScript engine, and only then started compiling. On fast connections the network was no longer the bottleneck; CPU time for decoding and compiling was, and all of it happened after the download, with the main thread paused.
The obvious fixes each cost something. A single optimizing compiler produced fast code but was slow to start. JavaScript engines compiled lazily at runtime, which avoided work but kept compilation on the main thread and waited for parsing to finish. And there seemed no way to compile before the file arrived, because the old API only accepted a complete ArrayBuffer.
Firefox 58 attacked both ends. Streaming compilation fed each downloaded chunk straight into the engine through the streaming API, and because a wasm module's code section comes before its data, compilation could start while megabytes of data were still in transit. A new tiered compiler added a baseline tier that built code 10-15x faster than the optimizing compiler, and its output ran only about 2x slower, so code began executing almost immediately; background threads then recompiled the whole module with the optimizer and hot-swapped it in. Both compilers split work by function across cores.
Because compile throughput now exceeded network throughput, the code was ready almost as soon as the last packet landed. Mozilla framed the change as making WebAssembly load like decoding an image rather than parsing JavaScript: no main-thread compile pause and no wait for the whole payload.
What it achieved
Stream bytes into a fast baseline tier as they arrive, run that code at once, and hot-swap in background-optimized code
Why it worked
Compiling the first packet hides download time inside CPU work instead of serializing download then compile.
A baseline tier that compiles 10-15x faster turns startup into a quick start; the roughly 2x-slower code runs while optimization proceeds.
Because wasm functions compile independently, the work spreads across cores instead of queueing on one thread.
Putting a module's code before its data lets streaming compile the expensive part while payload bytes are still arriving.
Each change shortens startup without changing the machine code that eventually runs, so peak performance is untouched.
What can be applied
When the bottleneck step waits for the whole input, start it on the first chunk and ship a cheap version first; upgrade it in the background instead of blocking
Aftermath
Firefox 58 shipped the streaming and tiered compiler in January 2018; the launch explainer drew a 912-point Hacker News thread. Mozilla's test page let users measure compile speed on their own devices, and the team said the groundwork was laid to cache compiled machine code in the HTTP cache, extending the JavaScript bytecode cache that shipped in the same release.
FOLLOW THE EVIDENCE
The sources
- Making WebAssembly even faster: Firefox's new streaming and tiering compiler hacks.mozilla.org
- Hacker News discussion: Making WebAssembly even faster news.ycombinator.com