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 — time to first byte (P50) | 135–150 ms | Direct GET of an already-cached asset. Near-identical across a 20 KB thumbnail, a 173 KB display variant, and a 1.5 MB original, because time-to-first-byte is dominated by connection setup and round-trips rather than by the size of the response. |
| Cached delivery — time to first byte (P99) | 170–225 ms | Same 40-request runs. The tail is network jitter on the client's path, not work done to serve the asset. |
| Connection setup (DNS + TCP + TLS) | ≈ 85 ms | The majority of the figures above, and paid once per connection. A page loading several images over a warm connection pays it once, not per image — repeat requests on a reused connection measured ≈ 99 ms median from the same client. |
| Full transfer — 20 KB thumbnail | ≈ 140 ms | Complete request to last byte. At this size the payload is essentially free; you are measuring the round-trip. |
| Full transfer — 173 KB display variant | ≈ 200 ms | The variant a page actually embeds. Generated once from a 5616 × 3744 original and served from cache thereafter. |
| Full transfer — 1.5 MB original | ≈ 380 ms | Worst case: the untouched original. The gap versus the display variant is the argument for embedding the variant. |
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 | ≈ 87 % smaller | Two photographic animated GIFs, 14 frames each: 1.8 MB → 237 KB and 2.6 MB → 346 KB, both a 7.5× reduction. Lossy WebP at quality 70, identical frame count and timing. This is the largest win the pipeline offers, by a wide margin. |
| PNG → WebP | 26–30 % smaller | Four 1200 × 800 interface captures — flat fills, text, chart bars. Consistent but nothing like the reduction photographic content sees, because PNG is already efficient on this kind of image. |
| JPEG → WebP | 0–19 % smaller | Four 1200 × 800 photographs, quality 82. The spread is wide and the median is only about 7 %: JPEG is already heavily quantised, so re-encoding at the same dimensions sometimes gains little. One of the four came out larger, and the pipeline discards a variant that is not smaller than its source rather than serve you a bigger file. |
| Where the real saving is | resize, not re-encode | Format conversion is the smaller half of the story for photographs. The display variant caps width at 1280px, so a 5616px camera original drops to a fraction of its size before the codec is considered at all. |
Reproduce it yourself
For latency, the simplest reproducer is curl against a delivery URL after warming the cache. You are measuring your own network path as much as ours, so expect your numbers to move with your distance from the nearest serving location — closer is faster, and a reused connection is faster again.
# 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 end-to-end client measurements, not server-side timings: 40 curl requests per asset from a single machine on an ordinary consumer connection, against a pre-warmed cache, opening a fresh connection each time. They therefore include DNS, TCP, TLS and the round-trip to whichever location served us — which is most of the number. Measure from your own client and you should land in the same range, better if you are closer to a serving location. Format-reduction numbers come from uploading a test set through the production pipeline and comparing each source against the variant it produced, with sources sized at or below the 1280px display width so no downscale is folded into the figure. The sample is small — four images per raster format, two GIFs — which is why ranges are quoted rather than one number.
Why are these honest and not 'four nines' marketing numbers?
Because the goal is to give you something you can verify, and a number you cannot reproduce is worth nothing to you. Plenty of services quote single-digit milliseconds by reporting only the time spent inside their own infrastructure. That figure is real, but it is not what your users experience: from a browser, connection setup and the round-trip dominate, and no provider can remove them. So the numbers here are what curl reports from an ordinary machine — the same thing you will measure.
Can I run the same benchmark against my own swiftimg account?
Yes, and please do. Upload a known asset, request the variant URL once to warm the cache, then measure with `curl -w '%{time_starttransfer}\n' -o /dev/null -s`. Expect time-to-first-byte in the low hundreds of milliseconds on a fresh connection, most of it connection setup — check `cf-cache-status: HIT` in the response headers to confirm you are measuring a cache hit and not a first generation. Reusing one connection across requests removes the handshake and drops the figure meaningfully.
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 against your own account rather than taking a marketing SLA on faith. Assets are served with a one-year immutable cache header, so a warmed asset stays warm.
Want this performance on your own images?
Upload anonymously to test, then grab the API and a custom domain on the Developer plan.