The Speed Benchmark: How Fast Is Browser-Only Processing, Really?
The assumption behind most upload-based tools is that a server has to do the heavy lifting because a browser can’t. We wanted an actual number, not an assumption — so we generated realistic test files, timed the processing with the browser’s own Performance API, and measured the output. Here’s exactly what we found.
Methodology
Two tools, two categories, both fully reproducible:
- Generate a realistic test file programmatically, in-browser — nothing pre-optimized or hand-picked to flatter the result.
- Feed it to the tool and trigger processing exactly as a user would.
- Time the operation using
performance.now(), from the moment processing starts to the moment the result appears. - Record the resulting file size and compare to the original.
No file was uploaded anywhere during this test — see our Privacy Audit for the network-level verification of that claim.
Results
Timed from clicking Compress to the output size appearing on screen, via the browser Performance API. The test image was generated with a gradient plus per-pixel random noise specifically so it wouldn’t compress trivially like a flat-color test image would — the goal was something that behaves like a real photo.
This one’s worth being precise about: minification here is synchronous regex processing, done within a single render — there is no meaningful multi-frame delay to measure. We’re not going to invent a millisecond figure our test harness can’t actually resolve accurately.
Honest Limits
Run It Yourself
This isn’t a number to trust on our word — it’s a test you can repeat with your own files on Image Compressor or CSS Minifier right now. Open DevTools’ Performance tab if you want to time it precisely, or just watch the size counter — either way, the result is yours to check, not ours to claim.
Frequently Asked Questions
Will I get the exact same speed and compression ratio?
The compression ratio will be very close — it depends mainly on the input file, not your device. Speed will vary. Unlike a server benchmark, which runs on the same hardware for every visitor, local processing runs on your CPU/GPU. A newer laptop will compress the same image faster than an older phone. That’s the honest tradeoff of processing on-device: the work moves to your machine instead of a server queue.
Why not benchmark against iLovePDF, Smallpdf, or other upload-based tools directly?
Because we’d be measuring their server queue times and our network conditions on a given day, not a stable, reproducible number — and because running automated tests against a third-party service to publish a competitive claim isn’t something we do without it being genuinely reproducible by a reader. What we can measure honestly, and what you can re-run yourself, is our own tools’ real performance. If you want to compare directly, run our test file through both and time it — that comparison is yours to make, and we’d rather you did it than take our summary of it.
Does a smaller file always mean lower quality?
Not necessarily, but there’s always a tradeoff dial somewhere. Image Compressor uses a fixed quality setting tuned for the visible-loss threshold on photographic content; the CSS Minifier is lossless — the minified output is functionally identical, just without whitespace and comments. We link every result to the actual tool so you can inspect the tradeoff yourself.
How were the test files generated?
Programmatically, in the same browser session used to run the test — a synthetic photo-like JPEG (gradient + random noise, so it doesn’t compress unrealistically well like a flat color would) and a synthetic but realistic CSS file (400 component rules with real property patterns, comments, and vendor prefixes). Using generated files means the test is exactly reproducible — no dependency on a specific photo or stylesheet you don’t have access to.