Benchmarks
What swiftimg actually does in production — measured numbers, no marketing rounding. If anything here doesn't match what you see in your own account, file an issue and we'll investigate.
Latency & throughput
| Scenario | Result | Notes |
|---|---|---|
| Cached delivery (P50) | 1–2 ms | Direct GET of a previously-served asset from `i.swiftimg.com`. Served from the global cache, region near client. |
| Cached delivery (P99) | < 3 ms | Same path, 99th-percentile in our last measurement window. Tail is dominated by network jitter, not origin work. |
| First-byte from origin storage | ≈ 2 ms | First-time fetch of an original when the global cache is cold, before it's served warm on every later request. |
| On-the-fly resize + encode (cold) | ≈ 150 ms | Our image pipeline generates a WebP variant from the original on the first request. Subsequent requests are cache hits. |
| Single-worker throughput | > 1,200 RPS | Synthetic test of a single process handling cache-hit GETs. Real-world ceiling is much higher; capacity scales out automatically. |
Format reduction
swiftimg generates WebP variants for grids automatically. These are the typical compression gains versus the source format.
| Scenario | Result | Notes |
|---|---|---|
| GIF → animated WebP (typical) | 5–10× smaller | Lossy WebP at ~75 quality via our GIF-to-WebP conversion. Identical frame count and timing. Holds across our public test set. |
| PNG → WebP at 80 quality | ~70 % smaller | Typical reduction for screenshots and UI captures. Visually indistinguishable side-by-side. |
| JPEG → WebP at 80 quality | ~25–35 % smaller | Smaller absolute gain because JPEG is already heavily quantised, but a meaningful saving on heavy galleries. |
Reproduce it yourself
For latency, the simplest reproducer is curl against a delivery URL after warming the cache. Run it from a region close to any global-CDN POP and you'll see the cached numbers above.
# Warm the cache, then measure
url="https://i.swiftimg.com/abc123.png"
curl -s -o /dev/null "$url" # warm
for i in 1 2 3 4 5; do
curl -s -o /dev/null -w 'total: %{time_total}s ttfb: %{time_starttransfer}s\n' "$url"
doneFor format reduction, upload a representative test set via the API and compare the original and the generated display / thumb variants.
Benchmarks FAQ
How are these numbers measured?
Latency figures are sampled from production traffic over a 24-hour window: cached-delivery P50/P99 are from the analytics pipeline. Origin / resize numbers are warmed-up wall-clock from the swiftimg worker, measured worldwide. Format-reduction numbers come from running the swiftimg pipeline against a fixed public test set of representative GIFs, PNGs, and JPEGs.
Why are these honest and not 'four nines' marketing numbers?
Because the goal is to give you something you can verify. The global cache really is 1–2 ms when the entry is hot; we don't claim sub-millisecond. Resize times depend on input size — 150 ms is the median, not the floor.
Can I run the same benchmark against my own swiftimg account?
Yes. Upload a known asset with curl, hit the variant URL twice to warm the cache, then measure with `curl -w '%{time_total}\n' -o /dev/null -s`. The first request should land in tens of milliseconds; subsequent ones should drop to single digits.
What about availability / uptime?
swiftimg targets 99.9% availability. The numbers on this page are reproducible — see the curl recipe above — so you can verify delivery speed and reliability against your own account rather than taking a marketing SLA on faith.
Want this performance on your own images?
Upload anonymously to test, then grab the API and a custom domain on the Developer plan.