wasm-opt - Shrinks WASM Bundles (When It Doesn't Crash)

Been using this for like two years now? Maybe more. It does work - took our bundle from... I think 2.3MB down to 1.8MB? Maybe 1.7MB. Point is, way smaller. Mobile users stopped bitching about load times, so that's something. But damn, this thing can be a pain sometimes.

It's the only WASM optimizer that actually does anything useful. Emscripten, wasm-pack, everyone just calls wasm-opt because what else are you gonna do? The thing reads your .wasm files, runs a bunch of optimization passes, and hopefully gives you back something smaller without breaking everything.

The Reality Check

Performance claims online are hit or miss. I usually get about 20% smaller files with -O3, sometimes better. Depends on what your compiler already optimized. The 2023 benchmarks show WASM runs about 2.3x slower than native - not amazing but not terrible.

Here's what I learned the hard way: -O4 is a trap. Takes forever for maybe 3% extra savings. Stick with -O3 unless every byte actually matters. Someone on our team set it to -O4 once and our CI started taking forever. Like, we'd go grab coffee and it still wasn't done. Had to change it back to -O3.

When It All Goes to Hell

Yeah, it crashes sometimes. Had it die on me twice with big modules - once was some memory overflow bullshit, another time it just said "validation error" and gave up. Check the GitHub issues if you want to see how many other people are having the same problems.

The real pain in the ass is when wasm-pack tries to auto-download wasm-opt and your corporate network blocks it. You get this cryptic error about download failures and your build is fucked. Solution: cargo install wasm-opt first so it uses the local copy.

Most of the time it works fine, but when it doesn't, you'll end up disabling it with wasm-opt = false in your Cargo.toml just to ship something that day.

wasm-opt has like 50+ optimization passes, but honestly, you don't give a shit about most of them. You care about -O1 through -O4 and that's basically it.

What Each Optimization Level Actually Does

I've been testing this on our image thing (can't say what exactly, but it processes a lot of images):

-O1: Fast and gives you maybe 10-15% smaller files. Use this for development when you just want to check if your code works without waiting around.

-O2: The sweet spot. Takes twice as long as -O1 but gives you most of the benefits. Use this for production unless you have a really good reason not to.

-O3: More aggressive stuff. Took our bundle from like 1.2MB down to... I think around 950KB? But builds started taking way longer. Worth it for releases though.

-O4: The "let's optimize everything and see what happens" level. Maybe 3-5% better than -O3 but takes forever. Only use this if every byte matters and you can afford to wait.

-Os/-Oz: Supposed to prioritize size over speed, but I honestly get better results with -O3 most of the time.

What Actually Gets Optimized

Dead code elimination is where you get the biggest wins. Throws away all the stdlib junk you imported but don't use. Seen 200KB+ savings from this alone, especially when you're pulling in tons of Rust crates.

Function inlining helps if you have tons of small utility functions. Sometimes it backfires and makes your binary bigger, but wasm-opt is usually pretty smart about when to inline and when not to.

Constant folding is nice but not revolutionary unless you're doing a lot of compile-time math. Basically just replaces 2 + 2 with 4 at compile time.

Build System Integration That Actually Works

Most build systems can just run wasm-opt as a post-build step:

## In your Makefile or whatever
wasm-opt -O3 target/wasm32-unknown-unknown/release/myapp.wasm -o optimized.wasm

Emscripten users: add -O3 to your compile flags and it runs wasm-opt automatically:

EMCC_CFLAGS=\"-O3\" emcc main.c -o output.wasm

Rust projects: wasm-pack handles this unless you disable it with wasm-opt = false in Cargo.toml.

When Optimization Breaks Everything

About twice a year, aggressive optimization breaks something weird. I've had -O4 completely break C++ modules that do exception handling. You'll get cryptic validation errors like "function signature mismatch" or runtime crashes with "memory access out of bounds."

When this happens, drop back to -O2 and ship it. Don't waste time debugging wasm-opt's optimization passes - the extra 5% size savings isn't worth debugging compiler internals for three days.