We broke the speed limit of the web. A deep engineering dive into how we combined Rust, WebAssembly, and SharedArrayBuffer to make image processing 20x faster than cloud APIs.
In the world of web performance, "Fast" is usually measured in milliseconds. Google tells us that if a site takes more than 3 seconds to load, 53% of users leave.
But at MojoDocs, we aren't satisfied with "Fast". We are chasing "Instant".
When you use a traditional image converter (like CloudConvert or Zamzar), there is an unavoidable friction. You upload. You wait for the progress bar. You wait for the server queue. You wait for processing. You wait for download.
This article explains the engineering architecture behind MojoDocs' "Zero Latency" experience—how we built a system where the processing happens literally as fast as your neurons can register the click.
The Enemy: Round Trip Time (RTT)
Before we talk about our solution, let's diagnose the problem. The bottleneck of the modern web isn't CPU speed; it's Light Speed.
In a cloud architecture (Server-Side):
- User Click -> Request travels 5000km to Data Center (Virginia). [200ms]
- Upload 10MB Image on Indian 4G. [8000ms]
- Server Queues Request. [1000ms]
- Server Processes Image. [500ms]
- Download 10MB Result. [5000ms]
Total Time: ~15 Seconds.
You cannot optimize the upload speed. You are limited by the user's ISP (Jio/Airtel). The only way to win is to delete the network step entirely.
The Solution: Bringing the Brain to the Browser
MojoDocs runs on a Client-Side First architecture. We don't send your data to our server. We send our server code to your browser.
1. The Core: Rust & WebAssembly
Javascript (JS) is great for UI, but terrible for heavy math. It is single-threaded and interpreted. If we tried to resize a 4K image in pure JS, your browser would freeze.
We wrote our core image engine in Rust. Rust gives us:
- Zero-Cost Abstractions: High-level syntax with assembly-level performance.
- No Garbage Collector: Unlike Go or Java, Rust manages memory manually. This prevents the random "Micro-Stutters" that happen when a GC runs.
We compile this Rust code into WebAssembly (WASM)—a compact binary format that runs at near-native speed inside Chrome/Firefox/Safari.
2. Parallelism: Web Workers & SharedArrayBuffer
Even with WASM, if we ran the code on the UI thread, the page would become unresponsive. You wouldn't be able to scroll.
MojoDocs spawns a pool of Web Workers (background threads). We use a browser feature called SharedArrayBuffer. This allows the UI thread and the Worker thread to access the same chunk of memory (the image pixels) without copying data back and forth.
Result: You can convert 50 images in the background while scrolling the page smoothly at 60fps.
Benchmark: MojoDocs vs The Cloud
We ran a test converting a batch of 100 JPEGs to PNGs on a standard MacBook Air (M1) vs a leading Cloud Competitor.
| Metric | Cloud API | MojoDocs (WASM) |
|---|---|---|
| Time to First Byte | 12.5s | 0.05s |
| Throughput (Images/Min) | 12 | 140+ |
| Offline Capability | No | Yes |
The SIMD Advantage
Modern CPUs have a feature called SIMD (Single Instruction, Multiple Data). It allows the processor to perform the same math operation on multiple pixels at once (e.g., "Make these 8 pixels brighter").
Javascript cannot touch SIMD. WASM can. Our Rust engine uses 128-bit SIMD instructions to process images 4x faster than standard loops.
Why Does This Matter to You?
You might not care about "Rust" or "SIMD". But you care about Flow State.
When you are working—converting assets for a presentation, or compressing photos for a website—every second of waiting breaks your focus. MojoDocs is designed to be invisible. It works so fast that the tool disappears, leaving only the task completed.
