Performance Benchmarks

How GetWebP CLI performs under various workloads, and why.

See also: README | Commands | Getting Started

Architecture Overview#

Understanding GetWebP's performance characteristics requires understanding its processing pipeline.

WASM Codec Pipeline#

GetWebP uses jSquash WASM codecs compiled from the same C/C++ libraries that power Google's Squoosh:

Each image goes through a three-stage pipeline:

Read file (I/O) --> Decode to RGBA (WASM) --> Encode to WebP (WASM) --> Write file (I/O)

Key implication: The WASM codecs run in the main thread (not native C). This means:

• Decode + encode is CPU-bound and runs at roughly 60--80% of native cwebp speed for equivalent operations.
• WASM initialization is a one-time cost. Four WASM modules (PNG decoder, JPEG decoder, WebP decoder, WebP encoder) are compiled from embedded binary blobs on first use, then cached for the session. This adds ~100--300ms to the first invocation.
• Memory overhead per image equals the raw RGBA bitmap (width x height x 4 bytes) plus the encoded WebP buffer. A 4000x3000 photo requires ~48 MB of transient memory.

Concurrency Model#

GetWebP uses async concurrency with p-limit, not OS-level threads or worker threads.

                    +--> [decode + encode file 1] --+
Main thread ------+--> [decode + encode file 2] --+--> results
   (event loop)    +--> [decode + encode file N] --+

• Starter/Pro plans default to os.cpus().length - 1 concurrent tasks (capped at 32). Configurable via --concurrency.
• Free plan is forced serial (1 task at a time) with a 3-second delay between files.

Because WASM execution blocks the JavaScript event loop during decode/encode, true parallelism is limited. However, I/O operations (file reads and writes) overlap with CPU work in other tasks, yielding measurable throughput gains up to approximately the number of CPU cores.

Note: A worker_threads implementation exists in the codebase but is not active. The jSquash WASM modules do not currently initialize reliably inside Node.js worker threads. If this is resolved upstream, thread-level parallelism would unlock near-linear scaling.

Benchmark Methodology#

Test Environment#

Benchmark date: 2026-04-05. Results vary by hardware, OS, disk speed, and image content.

Test Dataset#

Measurement Method#

# Single file
time getwebp convert photo.jpg -o /tmp/out
 
# Batch (wall-clock time)
time getwebp convert ./dataset -o /tmp/out --concurrency 4

All times are wall-clock. Each test is run 3 times; the median is reported.

Single-File Benchmarks#

Time to convert a single image at default quality (-q 80).

JPEG#

PNG#

PNG-to-WebP conversions typically yield the highest savings because PNG is lossless while WebP at quality 80 applies lossy compression.

BMP#

BMP files are uncompressed bitmaps. Conversion to WebP yields dramatic file-size reductions. Note that BMP decoding uses a pure JavaScript library (bmp-js) rather than WASM, which is slower for very large files but adequate for typical use.

WebP (Re-encode)#

Re-encoding WebP-to-WebP is useful for adjusting quality. Savings depend on the quality gap between input and output.

Batch Throughput#

Concurrency Scaling (Starter/Pro)#

50 JPEG files, average 3 MB each, on an 8-core machine:

Why scaling is sub-linear: GetWebP uses async concurrency within a single process, not OS threads. WASM codec execution blocks the event loop during each decode/encode call. Concurrency gains come from overlapping I/O (file reads/writes) with CPU work in other tasks. Beyond the CPU core count, additional concurrency adds scheduling overhead without improving throughput.

Recommended setting: Leave at default (CPU cores - 1). Setting --concurrency higher than your core count provides diminishing returns.

Large Batch (1,000 files)#

Mixed dataset: 600 JPEG + 300 PNG + 100 BMP, various sizes, on an 8-core machine at default concurrency:

Plan Comparison#

Processing 50 JPEG files (avg 3 MB each) on an 8-core machine:

Free Plan Timing Breakdown (10 files)#

File  1: ~1.2s  (convert)
         3.0s   (mandatory delay)
File  2: ~1.2s
         3.0s
...
File 10: ~1.2s
─────────────────────────
Total:   ~12s converting + ~27s delays = ~39s

The 3-second inter-file delay on the Free plan is the dominant bottleneck, not the conversion itself. Upgrading to Starter or Pro removes this delay entirely and enables parallel processing.

Quality vs File Size vs Speed#

All measurements on a single 4000x3000 JPEG (~3 MB):

Recommendation: Quality 75--80 offers the best balance of file size and visual fidelity for web delivery. Use 90+ for photography portfolios or print-quality assets.

Comparison with Other Tools#

Single-image conversion, -q 80, median of 5 runs (2026-04-05, Apple Silicon arm64):

Key takeaway: GetWebP is ~2x slower on raw encode (WASM vs native), but output sizes are identical — same libwebp codec, same quality. The trade-off is zero dependencies vs. raw speed.

Analysis#

GetWebP vs cwebp: Both use libwebp for encoding, so output quality and file sizes are nearly identical at the same quality setting. The performance gap comes from WASM overhead (~1.3--1.6x slower than native). GetWebP's advantage is zero-dependency cross-platform distribution and batch processing with concurrency.

GetWebP vs sharp: Sharp links directly to native libvips, making it the fastest option. However, it requires Node.js and platform-specific native binary compilation. GetWebP ships as a self-contained Bun-compiled binary.

GetWebP vs Squoosh CLI: Both use the same jSquash/Squoosh WASM codecs. Performance is comparable. Squoosh CLI is deprecated; GetWebP is actively maintained.

GetWebP vs ImageMagick: ImageMagick's WebP encoder is typically less optimized than libwebp. GetWebP produces smaller files at equivalent visual quality.

When to Choose GetWebP#

• CI/CD pipelines: Single binary, no runtime dependencies, JSON output, exit codes for scripting.
• Cross-platform teams: Same binary on macOS (ARM + Intel), Linux, and Windows.
• Batch jobs: Built-in concurrency, recursive scanning, --skip-existing for incremental builds.
• No native compilation: Avoids the node-gyp / platform-specific addon issues that sharp requires.

Parallel Throughput Comparison#

When concurrency is factored in, the gap narrows. 50 JPEG files on an 8-core machine:

GetWebP's built-in concurrency makes it competitive with native tools that require manual parallelization wrappers.

When Native Tools May Be Better#

• Maximum throughput: If processing millions of images and every millisecond counts, native cwebp or sharp will be faster per image.
• Advanced transforms: If you also need resizing, cropping, or format conversion beyond WebP, sharp or ImageMagick offer a broader feature set.

Memory Usage#

GetWebP's memory consumption is dominated by raw pixel buffers during decode/encode:

Example: 8-core Machine, Default Concurrency (7)#

Processing 4000x3000 images:

WASM init:          ~30 MB
7 concurrent images: 7 * 48 MB = ~336 MB
Overhead (buffers, GC): ~50 MB
────────────────────────────
Peak estimate:       ~416 MB

Reducing Memory Usage#

• Lower concurrency: --concurrency 2 reduces peak memory to ~130 MB for the same images.
• Smaller images: Web-resolution images (1920x1080) use ~8 MB per decode buffer, totaling ~90 MB at concurrency 7.
• BMP caution: Large BMP files require an extra full-frame buffer for the BGR-to-RGB channel swap. A 36 MB BMP (4000x3000) allocates ~96 MB during decode.

Startup Time#

For single-file conversion, startup overhead is a significant fraction of total time. For batch jobs (100+ files), it is negligible.

Optimization Tips#

For Maximum Throughput#

# Use all cores on a dedicated build machine
getwebp convert ./images -r --concurrency 8
 
# Skip already-converted files in incremental builds
getwebp convert ./images -r -o ./dist --skip-existing
 
# Lower quality for faster encoding (quality < 80 is slightly faster)
getwebp convert ./images -q 70

For Minimum Memory#

# Limit concurrency to reduce peak memory
getwebp convert ./images --concurrency 2
 
# Process directories one at a time instead of recursive
getwebp convert ./images/thumbs -o ./out/thumbs
getwebp convert ./images/photos -o ./out/photos

For CI/CD Pipelines#

# JSON output + exit codes for scripted error handling
getwebp convert ./assets -r -o ./dist --skip-existing --json
echo "Exit code: $?"
 
# Dry run to validate before converting
getwebp convert ./assets -r --dry-run --json

Running Your Own Benchmarks#

To generate numbers for your specific hardware:

# Prepare a test dataset
mkdir -p /tmp/bench-input /tmp/bench-output
# Copy or generate test images into /tmp/bench-input
 
# Single-file timing
time getwebp convert /tmp/bench-input/sample.jpg -o /tmp/bench-output
 
# Batch with default concurrency
time getwebp convert /tmp/bench-input -o /tmp/bench-output
 
# Batch with JSON output for machine-parseable results
getwebp convert /tmp/bench-input -o /tmp/bench-output --json > results.json
 
# Concurrency sweep
for c in 1 2 4 8 16; do
  rm -rf /tmp/bench-output/*
  echo "concurrency=$c"
  time getwebp convert /tmp/bench-input -o /tmp/bench-output --concurrency $c
done
 
# Memory monitoring (macOS)
/usr/bin/time -l getwebp convert /tmp/bench-input -o /tmp/bench-output
 
# Memory monitoring (Linux)
/usr/bin/time -v getwebp convert /tmp/bench-input -o /tmp/bench-output

Write Safety#

GetWebP uses atomic writes to prevent corrupted output files:

1. Encode output is written to a temporary file (<name>.webp.tmp).
2. The temporary file is renamed to the final path (<name>.webp) via fs.rename.
3. On SIGINT (Ctrl+C), any in-progress .tmp files are cleaned up automatically.

This means a crash or interruption will never leave a half-written .webp file in your output directory. Already-completed files are safe. Use --skip-existing on the next run to resume from where you left off.

Known Limitations#