Why We Moved Our Cryptography to WebAssembly (Wasm): A Real-World Performance Case Study

Building client-side development tools is a balancing act. On one hand, you want to keep the application 100% client-side to guarantee privacy—ensuring no data is sent to a remote database. On the other hand, running compute-heavy operations like file compression, key generation, or password hashing in single-threaded JavaScript can lock up the browser UI and frustrate users.

When we first launched our suite of cryptographic tools, we implemented everything in pure JavaScript. However, as users started using our tools for bulk operations and larger file sizes, we saw noticeable performance bottlenecks. I once sat watching a browser tab freeze for over **eight seconds** while generating a complex RSA-4096 key pair or hashing a 100MB file using SHA-3. That was the moment we decided to migrate our cryptographic engines to WebAssembly (Wasm).

In this article, I will share our journey migrating from JavaScript-based cryptography to Rust compiled to WebAssembly, provide raw benchmark data, and show you how to leverage Wasm in your own applications.

The Limits of JavaScript for Cryptography

JavaScript is an incredibly fast scripting language thanks to modern Just-In-Time (JIT) compilers like V8. However, JS has several inherent limitations that make it unsuitable for high-performance mathematical operations:

1. Single-Threaded Event Loop: Since JavaScript runs on a single main thread by default, any long-running cryptographic calculation blocks the event loop. The UI becomes completely unresponsive: buttons cannot be clicked, animations freeze, and the browser eventually displays an "Aw, Snap!" or "Page Unresponsive" warning.
2. Dynamic Typing and Garbage Collection: JavaScript handles memory allocation dynamically. In cryptography, where you are constantly allocating, manipulating, and discarding thousands of tiny byte arrays (typed arrays), garbage collection pauses accumulate rapidly, causing stuttering performance.
3. Lack of Low-Level Bitwise Optimizations: Cryptographic algorithms (like SHA-256 or AES) are essentially long series of bitwise operations (AND, OR, XOR, rotations) on fixed-size integers. While JavaScript supports bitwise operations, it historically treats numbers as 64-bit floating-point values internally, forcing the engine to convert back and forth between float and 32-bit integer representations on every bitwise step.

The Solution: WebAssembly (Wasm)

WebAssembly is a binary instruction format that runs in the browser at near-native execution speed. It acts as a compilation target for low-level languages like C, C++, and Rust. WebAssembly doesn't replace JavaScript; it runs alongside it, allowing you to delegate heavy calculations to compiled modules.

By writing our core hashing and encryption utilities in **Rust** and compiling them to Wasm using `wasm-pack`, we bypassed JavaScript’s execution limitations. Rust gives us deterministic memory management, zero-cost abstractions, and compiler-level optimizations that compile down directly to highly efficient machine code instructions.

The Benchmarks: JavaScript vs. WebAssembly

To measure the impact, we ran a series of head-to-head benchmarks on a standard MacBook Air (M1, 8GB RAM). We tested three common operations: hashing a 50MB file with SHA-256, hashing a password with Argon2id (10 iterations, 64MB memory), and generating a 4096-bit RSA key pair.

Operation	Pure JS Engine	Rust Wasm Engine	Performance Gain
SHA-256 (50MB File)	1,840 ms	210 ms	8.7x Faster
Argon2id Password Hash	4,120 ms	480 ms	8.5x Faster
RSA-4096 Key Gen	8,450 ms	1,290 ms	6.5x Faster

As the benchmarks show, WebAssembly outperformed JavaScript by **over 800%** on file hashing and password stretching operations. In addition, during the RSA key generation, the JavaScript implementation caused the browser UI to stutter and freeze, whereas the Wasm implementation finished so quickly that the user noticed no layout degradation.

How We Built the Wasm Pipeline

Here is a simplified look at how we compile and load our Rust cryptography functions into the browser.

Step 1: Write the Core in Rust

We use Rust’s standard ecosystem crates (like the `sha2` crate) and expose them to JavaScript via `wasm-bindgen` annotations.

// Rust core module (src/lib.rs)
use wasm_bindgen::prelude::*;
use sha2::{Sha256, Digest};

#[wasm_bindgen]
pub fn hash_sha256(data: &[u8]) -> String {
    let mut hasher = Sha256::new();
    hasher.update(data);
    let result = hasher.finalize();
    format!("{:x}", result)
}

Step 2: Build the Wasm Bundle

We build the module target using `wasm-pack`, which compiles the Rust code into a `.wasm` binary file and generates helper JavaScript bindings.

# Build Wasm module for web target
wasm-pack build --target web --release

Step 3: Load and Execute in JavaScript

We initialize the compiled binary on demand in our frontend code. Here is how we hook it up to our tool interfaces:

import init, { hash_sha256 } from './pkg/wasm_cryptography.js';

async function runHasher() {
  // 1. Initialize the Wasm module
  await init();

  const fileInput = document.getElementById('file-input');
  fileInput.addEventListener('change', async (e) => {
    const file = e.target.files[0];
    const buffer = await file.arrayBuffer();
    const uint8Array = new Uint8Array(buffer);

    console.time('Wasm-Hash');
    // 2. Pass data to WebAssembly memory space
    const hash = hash_sha256(uint8Array);
    console.timeEnd('Wasm-Hash');

    document.getElementById('output').textContent = hash;
  });
}
runHasher();

Handling the UI Thread: Web Workers

Even with WebAssembly running at near-native speeds, a calculation that takes over a second (like generating RSA-4096 keys) can still cause minor UI stutters if run on the main thread. To achieve a completely fluid user experience, we combined WebAssembly with **Web Workers**.

Web Workers allow you to run JavaScript files in the background, entirely separate from the main browser window. By instantiating and running our Wasm cryptographic module inside a background Web Worker, we ensured that the browser UI thread remains 100% idle, keeping user interactions silky smooth.

Conclusion: Is Wasm Always the Best Choice?

Moving our core mathematical tooling to WebAssembly was a massive win for our site. We achieved speeds that were previously impossible in the browser, reduced memory footprint, and guaranteed privacy by keeping all operations local.

However, Wasm is not a replacement for everything. If your app only needs simple math, string operations, or DOM manipulations, JavaScript is still the most efficient choice because Wasm has a small boundary cost when copying data back and forth between JS memory and Wasm memory. But for heavy cryptographic calculations, hashing, or formatting engines, WebAssembly is the ultimate secret weapon for modern developer platforms.