The crate is built with cargo build --release --features=simd --target=wasm32-unknown-unknown which aliases DefaultCDF16 type to the SIMD types. However since

The crate is built with cargo build --release --features=simd --target=wasm32-unknown-unknown which aliases DefaultCDF16 type to the SIMD types. However since WASM doesn't support vectorized instructions yet, I believe LLVM translates these to scalar and the result is actually 20% slower on both Firefox and Chrome than without the SIMD enabled. Compared to the speed of the native binaries in https://blogs.dropbox.com/tech/2018/06/building-better-compression-together-with-divans/ https://blogs.dropbox.com/tech/2018/06/building-better-compr... the Firefox WASM binary seem to decode DivANS roughly 3x slower than native without multithreading at around 100 Mbit/s. Chrome goes more than 12x slower, running at around 20 Mbit/s. I'm a bit surprised that there is such a big performance gap between the browser and the native binaries. This may be a reason to look further at the generated wasm and see where the time is being spent.