Last week I needed to compress 1000 product photos for a site migration. Uploading them to a cloud compressor would take hours and cost money. So I built a browser-local compressor and ran the benchmark myself.
The Setup
I built compress2png.com using Canvas API for client-side compression. The workflow: load image → render to Canvas → export with quality parameter → compare sizes.
The Results (1000 images, avg 3.2MB each)
- Server upload approach: 47 minutes (mostly upload time on a 50Mbps connection)
- Browser-local: 8 minutes 12 seconds
- Best compression rate: 73% size reduction at quality 0.7 (visually indistinguishable)
- Worst case: PNGs with alpha transparency — only 15% reduction without visible quality loss at quality 0.9
What Actually Matters
Quality 0.7 is the sweet spot. At 0.7, JPEG output is visually identical to the source but 60-75% smaller. Going below 0.6 introduces visible artifacts in gradients and text.
WebP beats JPEG at every quality level. Converting to WebP instead of JPEG gives 25-35% smaller files at the same visual quality. The tradeoff: Safari doesn’t fully support WebP Canvas operations.
Memory management is critical. Processing 1000 images sequentially crashed Chrome twice before I added explicit garbage collection. The fix: process in batches of 50, revoke Object URLs after each batch.
OffscreenCanvas is worth it. Moving rendering off the main thread kept the UI responsive. Without it, the browser tab was frozen for the full 8 minutes.
The Parallel Tools
I applied these same patterns to:
- svg2png.org — SVG vector conversion with batch processing
- genbarcode.org — GS1 barcode generation in the browser
Client-side processing is fast enough for production use. Don’t upload files you can process locally.
답글 남기기