Benchmarks
imagor is one of the fastest image processing servers available today.
That comes from the combination of libvips, the Go binding vipsgen, and imagor's streamed processing path. imagor keeps the request path close to libvips, avoids unnecessary buffering and copies for common streamed inputs, and exposes a libvips-friendly source path that works well for resize and thumbnail workloads.
Benchmark summary
Last updated: May 2026.
This summary is based on recent reruns from the public image-servers-benchmark project. The committed summaries for this rerun are available in the benchmark results.
On this benchmark set, imagor 1.9.1 is consistently faster than thumbor overall and competitive with imgproxy.
Why imagor is fast
imagor uses libvips for image processing and vipsgen for low-level libvips integration from Go. vipsgen provides generated, type-safe libvips bindings with streaming support, which helps keep the integration robust while staying close to libvips. For streamed sources, imagor keeps the data path efficient before the image even reaches the processing stage.
In practice, the main speed advantages come from a few places:
- imagor prepares streamed inputs in a way that libvips can consume efficiently
- blob reuse reduces avoidable reader churn after content sniffing and source preparation
- fanout and shared-reader handling reduce duplicated work around streamed sources
- the seekable libvips source path lets libvips load and process common inputs more efficiently
- libvips itself is highly optimized for resize, thumbnail, and transcode workloads
Quick comparison:
JPEG
PNG
WebP
AVIF
Benchmark shape:
- AWS EC2
c7i.large 2 VUs,5m,10swarmup- resize to
512x512 - public
image-servers-benchmarkproject with the rerun configuration documented in the linked benchmark summaries - compared runtimes:
- imagor:
ghcr.io/cshum/imagor:1.9.1 - imgproxy: benchmark project used
darthsim/imgproxy:latest, corresponding to imgproxyv4.0.3 - thumbor: local
benchmark-thumbor:latest, resolved fromthumbor/Dockerfiletothumbor 7.7.7
- imagor:
Representative throughput from the committed summaries:
| Format | imagor | imgproxy | thumbor |
|---|---|---|---|
| JPEG | 74.35 req/s | 82.01 req/s | 59.45 req/s |
| PNG | 18.56 req/s | 17.35 req/s | 10.23 req/s |
| WebP | 21.23 req/s | 24.27 req/s | 15.80 req/s |
| AVIF | 17.77 req/s | 17.15 req/s | 14.85 req/s |
The exact ranking still depends on image format, output settings, source shape, and deployment environment. The measured result from the current benchmark set is that imagor is one of the fastest image processing servers, clearly ahead of thumbor overall and competitive with imgproxy across common formats.
Notes
- imagor and imgproxy are both libvips-based, so the gap is often determined by request-path overhead, source handling, and encoder settings rather than by the core image library alone
- thumbor remains a strong compatibility reference, but its Pillow-based pipeline is generally slower on this workload
- for AVIF, encoder settings matter a lot; benchmark conclusions should always be read together with the exact runtime configuration
FAQ
Is imagor faster than thumbor?
Yes on this benchmark set. imagor outperformed thumbor on JPEG, PNG, WebP, and AVIF on AWS c7i.large.
Is imagor faster than imgproxy?
Not in every case. In this run, imagor led on PNG and AVIF, while imgproxy led on JPEG and WebP. The result depends heavily on encoder defaults, quality settings, and the image mix.
What makes imagor fast?
imagor combines libvips, generated vipsgen bindings, and a streamed request path designed to reduce unnecessary copies and source-handling overhead before decode and transform.
How were these benchmarks run?
The rerun used AWS EC2 c7i.large, 2 VUs, 5m, 10s warmup, and a 512x512 resize workload. The benchmark setup and committed summaries are linked from the public repository so the setup can be reviewed and rerun.
Are the results reproducible?
Yes. The page links to the public benchmark project and the committed result summaries used for this write-up, so readers can inspect versions, workload shape, and output settings.
