For the last decade, the workflow for optimizing web assets has been fundamentally broken.
You finish a design in Figma. You export a high-res PNG. Then, you open a browser tab, navigate to a site like TinyPNG or Squoosh, upload your file to a stranger's server, wait for a processing queue, and download the result.
It works, but it incurs three hidden costs that we rarely talk about:
- Latency: The network round-trip time (RTT).
- Reliability: Reliance on an external API or internet connection.
- Privacy: The "Black Box" problem.
At GetWebP, we believe the browser is the new operating system. With the maturation of WebAssembly (WASM), there is no longer a technical justification for sending images to the cloud just to make them smaller.
The Privacy "Black Box"#
When you drag a confidential product mockup or a screenshot containing PII (Personally Identifiable Information) into a cloud converter, you are technically creating a data breach.
Most free online converters state in their Terms of Service that they "reserve the right to store images for improvement purposes."
If you are working on an unreleased product under NDA, uploading assets to a third-party server is a violation of your contract.
Local-first architecture solves this by design, not by policy. In GetWebP, the image data never leaves the memory of your Chrome tab. The conversion logic (the C++ encoder) comes to the data, rather than the data going to the logic.
How We Ported libwebp to the Browser#
To achieve native-like performance without a server, we utilized WebAssembly. We compiled Google's reference implementation of libwebp directly into a WASM binary.
This means when you use GetWebP, you aren't running "JavaScript optimization" (which is slow). You are running native C++ code inside a sandboxed browser environment.
Here is a simplified view of our execution pipeline:
Context Capture
When you right-click "Save as WebP", the extension captures the Blob or Canvas data directly from the DOM.
WASM Bridge
The binary data is passed to the WebAssembly shared memory buffer. This happens in microseconds.
Encoding
The WASM thread runs the compression algorithm (Lossy or Lossless) using the CPU's full power, parallelizing where possible.
Write to Disk
The resulting .webp buffer is streamed directly to your Downloads folder using the Chrome Downloads API.
Benchmarking: Cloud vs. Local#
We tested a batch of 50 High-Res Marketing Assets (Total: 145MB).
| Metric | Cloud API (TinyPNG) | Local WASM (GetWebP) |
|---|---|---|
| Upload Time | 42s (on 50Mbps) | 0s (N/A) |
| Processing | 15s | 8s |
| Download Time | 35s | 0s (Instant Write) |
| Total Time | ~92s | ~8s |
| Privacy Risk | High | Zero |
The difference isn't just marginal; it's an order of magnitude. By removing the network bottleneck (I/O bound), the process becomes purely CPU bound.
Integrating into the Developer Workflow#
Tools should inhabit the environment where work happens. For web developers, that environment is the browser.
We designed GetWebP to live inside the Context Menu. This allows for "Contextual Optimization"—grabbing an image straight from a staging server, optimizing it, and saving it for production, without ever opening a file explorer.
// How we inject into the browser context
{
"permissions": ["contextMenus", "activeTab"],
"background": {
"service_worker": "background.js"
},
"context_menus": [
{
"id": "save-as-webp",
"title": "GetWebP - Save as WebP",
"contexts": ["image"]
}
]
}
The Future is Offline#
We are entering an era where Edge Computing moves closer and closer to the user. The ultimate edge is the user's own device.
By switching to local-first tools like GetWebP, you aren't just saving a few seconds. You are adopting a workflow that is resilient, private by default, and respectful of your bandwidth.
Stop uploading your assets. Let your browser do the work.