How Long Should Image Compression Take? Benchmarking 8 Popular Tools

Nobody markets an image compressor as slow. Every tool on the market claims to be fast. But "fast" gets measured in wildly different ways — some tools count only the encode step, some count from click to download, and almost none count the part where you sit watching a progress bar because your 40-image batch is queued behind someone else's.

This article does two things. First, it breaks down where the seconds actually go, which turns out to be a much more useful question than which tool "wins." Second, it gives you a reproducible methodology so you can benchmark any tool yourself in about fifteen minutes.

---

Table of Contents

1. Why Compression Speed Is Measured Wrong
2. The Four Components of Compression Time
3. Architecture Determines Almost Everything
4. How Format Choice Affects Encode Time
5. How to Run the Benchmark Yourself
6. What Good Looks Like: Target Times
7. The Batch Problem
8. Choosing a Tool for Your Workflow
9. Frequently Asked Questions

---

1. Why Compression Speed Is Measured Wrong

Most speed claims measure encode time — how long the compression algorithm takes to process the pixels. That's the one number that's easy to instrument and the one number that matters least to you.

What you experience is wall-clock time: from the moment you drop files in, to the moment optimized files are sitting on your disk. For a server-based tool, encode time is often the smallest slice of that. You can have a blazingly fast encoder sitting behind a two-second upload and a queue.

The right question isn't "how fast is the algorithm." It's "how many seconds of my life does this cost per batch, and how does that scale when the batch is 50 files instead of one."

---

2. The Four Components of Compression Time

Client-side tools eliminate the first, second, and fourth components entirely. That's the whole architectural argument in one sentence: browser-based compression has one component where server-based compression has four.

The asymmetry matters more than people expect because home and office upload bandwidth is typically a fraction of download bandwidth. On a connection with 20 Mbps upstream, a batch of twenty 4 MB photos is roughly 32 seconds of pure upload before any compression begins. The same batch encodes locally in a fraction of that.

---

3. Architecture Determines Almost Everything

Tools fall into four architectural categories, and category predicts performance far better than brand.

Expected wall-clock ranges for a single 4 MB, 3000 × 2000 px JPEG → WebP at quality 82, on a mid-range laptop with a 20 Mbps upstream connection:

The gap widens dramatically with batch size, because upload time scales linearly with total bytes while local encoding can use multiple CPU cores.

---

4. How Format Choice Affects Encode Time

Encoding cost is not equal across formats. This is the one place where a client-side tool can feel slow, and it's worth understanding why.

AVIF's encode cost is real — a large image that takes 50 ms as JPEG can take well over a second as AVIF. Three things to keep in mind:

• It's a one-time cost. You encode once and serve millions of times. Your visitors experience only decode time, which is fast.
• It's the reason some tools quietly cap AVIF quality settings or restrict AVIF to smaller images.
• It's why AVIF batch jobs should run at build time, not interactively, when you're processing hundreds of files.

If you're benchmarking tools, compare like with like. A tool that looks slow may simply be defaulting to AVIF while its competitor defaults to WebP.

---

5. How to Run the Benchmark Yourself

Fifteen minutes gets you defensible numbers for your own workflow — which are more useful than anyone else's numbers anyway.

How to benchmark a compression tool

1. Build a fixed test set. Use the same files for every tool. A representative set: five photographs (~4 MB each, 3000 × 2000 px), three PNG screenshots (~2 MB each), and two large hero images (~8 MB, 4000 × 2500 px).
2. Fix the settings. Same output format, same target quality (82 is a good standard), same output dimensions. Any tool compared at different settings is not being compared.
3. Measure wall-clock time, not reported time. Start a stopwatch when you click "compress" or drop the files. Stop it when the last optimized file is on your disk. Ignore whatever the tool's own progress readout claims.
4. Record your connection speed at test time. Run a speed test immediately before and note both up and down. Server-based results are meaningless without it.
5. Run each test three times and take the median. First runs include cold caches, WASM module downloads, and cold server workers.
6. Test three batch sizes: 1 file, 10 files, 50 files. The shape of the scaling curve is more revealing than any single number.
7. Record output quality, not just speed. Note the resulting file size and check a fixed detail region visually. A tool that's fast because it compresses badly hasn't won anything.
8. Test on a throttled connection too. In DevTools, set the network to "Slow 4G" and repeat the single-file test. This simulates working from a hotel, a train, or a client site — and it's where architecture differences become brutal.

What to record

---

6. What Good Looks Like: Target Times

Use these as pass/fail thresholds when evaluating any tool.

That last row is underrated. A tool that shows you the first compressed file immediately feels far faster than one that processes silently and dumps everything at the end, even at identical total throughput. Perceived speed is real speed for a workflow you repeat daily.

---

7. The Batch Problem

Single-file benchmarks flatter server-based tools. Batch benchmarks expose them.

Three things go wrong at scale with upload-based compression:

• Upload time is additive and unavoidable. 50 files × 4 MB = 200 MB. On a 20 Mbps upstream, that's over 80 seconds before any compression starts.
• Free tiers throttle. Most free online compressors cap batch size (commonly 20 files), cap file size, or rate-limit per hour. You end up splitting a job into four batches and babysitting it.
• Failures are expensive. A dropped connection at 90% doesn't cost you a retry of one file — it costs the whole batch.

Client-side tools have the opposite failure mode: they're bounded by your device's CPU and memory. A very large batch of very large images on an older laptop will be slow, and a phone will be slower still. That's an honest tradeoff, and it's a predictable one — it scales with your hardware, not with someone else's server load.

---

8. Choosing a Tool for Your Workflow

For most people the answer is simply: use a client-side browser tool for ad-hoc work and a CLI for anything that runs more than once. The category of "upload your images to a free website and wait" has no remaining advantage — it was a workaround for a time when browsers couldn't encode images, and browsers can now.

---

9. Frequently Asked Questions

Why does the first compression in a browser tool feel slower than the rest? The browser downloads and compiles the WebAssembly encoder module on first use. That's typically a few hundred milliseconds, paid once per session. Every subsequent file skips it.

Is client-side compression lower quality than server-side? No. Both typically use the same underlying encoders — libwebp, mozjpeg, libaom — compiled to WebAssembly rather than native code. WASM runs somewhat slower than native, but produces byte-identical output at the same settings.

Does compressing on my phone work? Yes, but expect it to be several times slower than a laptop, and expect memory limits on very large images or long batches. For a handful of images it's fine; for a 50-image batch, use a computer.

Should I benchmark output quality too? Absolutely. Speed without a matched compression ratio is meaningless. Record output file size alongside every timing, and eyeball a fixed detail region at 100%.

How much does encode speed matter for my site's visitors? Not at all directly — they only decode. Encode speed matters for your workflow, and workflow friction is why unoptimized images ship in the first place.

---

The Short Version

1. Measure wall-clock time from drop to download, not the algorithm's encode time.
2. Server-based tools pay upload + queue + download costs that client-side tools don't have.
3. AVIF encodes 15–30× slower than JPEG. Compare tools at the same output format.
4. Benchmark at 1, 10, and 50 files — the scaling curve reveals more than any single figure.
5. Always record output file size alongside timing. Fast and bad is not fast.

Try the client-side end of the spectrum — compress a batch in your browser and time it yourself.