Benchmark report · Measured October 17, 2026

Image optimization: size, speed, and visual quality

How much smaller does an image get, how long does that take, and does it still look the same? We sent 54 openly licensed images through Transloadit’s production API, repeated every parameter set 3 times, and scored each result against its source.

Results at a glance

JPEG, default settings

84.7%

Median size reduction for camera JPEGs with the Image Optimize Robot’s default settings, at a median SSIM of 0.973.

WebP versus JPEG

25.7%

Fewer bytes than JPEG when both are encoded at quality 75, at a median SSIM of 0.951 versus 0.951.

Robot time per image

0.48 sec

Median time the Image Resize Robot needed to encode one 768 × 512 image as WebP at quality 75.

Sample size

882

Assemblies behind this report: 294 file and parameter combinations, 3 runs each.

How to read the numbers

Four measurements per Assembly

Size reduction
1 − output bytes ÷ input bytes. 0% means the file did not change, 50% means it is half the size, and a negative value would mean the output grew.
SSIM
Structural similarity between the result and its source, from 0 to 1. A score of 1.000 means the pixels are identical, so the step was lossless. Lower scores mean more visible change.
Robot time
Seconds the Robot spent executing the Step, as reported by the API for each result. It excludes the upload and time spent waiting in a queue.
Assembly duration
The execution duration the API reports for the whole Assembly. On top of Robot time it covers handling the upload, reading the result’s metadata, and storing the result.

Finding 1

Optimizing a file in its own format depends on the parameters

The Image Optimize Robot keeps the file format and runs one or more optimizers, then returns the smallest result. For JPEG, the default settings produced a median reduction of 84.7% at a median SSIM of 0.973: the Robot re-encoded the image. With metadata removed, the same priority only applied lossless optimizers, so the pixels stayed identical and the median reduction was 5.5%. Choosing conversion-speed gave 4.6% in 1.26 sec of Robot time instead of 2.37 sec.

PNG behaved the other way around. Lossless optimization saved a median of 8.9%, and PNG was the slowest format in the benchmark at 10.70 sec of Robot time. Allowing lossy optimization and removing metadata saved 60.3% at a median SSIM of 0.997, in 1.96 sec of Robot time. WebP inputs were re-encoded, for a median reduction of 32.9% at a median SSIM of 0.964.

Image Optimize Robot results per source format and parameter set
SourceParametersMedian size reductionMedian SSIMMedian Robot time90th percentile Robot timeMedian Assembly duration
JPEGpriority: compression-ratiopreserve_meta_data: true84.7%0.9732.33 sec2.65 sec3.35 sec
JPEGpriority: compression-ratiopreserve_meta_data: false5.5%1.0002.37 sec2.82 sec3.64 sec
JPEGpriority: conversion-speedpreserve_meta_data: true4.2%1.0001.21 sec1.54 sec2.36 sec
JPEGpriority: conversion-speedpreserve_meta_data: false4.6%1.0001.26 sec1.57 sec2.18 sec
PNGlossy: falsepreserve_meta_data: true8.9%1.00010.70 sec26.17 sec11.64 sec
PNGlossy: falsepreserve_meta_data: false8.9%1.00010.70 sec25.90 sec11.48 sec
PNGlossy: truepreserve_meta_data: true8.9%1.00010.74 sec26.11 sec11.45 sec
PNGlossy: truepreserve_meta_data: false60.3%0.9971.96 sec2.45 sec2.91 sec
GIFpreserve_meta_data: true37.4%Not scored2.08 sec3.94 sec2.89 sec
WebPpreserve_meta_data: true32.9%0.9640.93 sec2.54 sec1.81 sec
WebPpreserve_meta_data: false33.1%0.9641.01 sec2.71 sec1.72 sec
SVGpreserve_meta_data: true47.3%Not scored1.32 sec2.06 sec2.17 sec
SVGpreserve_meta_data: false47.3%Not scored1.60 sec2.03 sec2.55 sec

Six source files per format. Animated GIF and SVG results are not scored because they have no single raster frame to compare.

Finding 2

WebP and AVIF reach the same similarity as JPEG in fewer bytes

Starting from lossless PNG photographs, the Image Resize Robot wrote JPEG, WebP, and AVIF at three quality settings without changing the dimensions. At quality 75, WebP needed 25.7% fewer bytes than JPEG while scoring a median SSIM of 0.951 against 0.951. AVIF at quality 75 needed 31.0% fewer bytes than JPEG at quality 90, at a median SSIM of 0.978 against 0.976. Quality settings are not comparable across formats, so compare rows by SSIM and size together.

Image Resize Robot results per output format and quality setting
OutputQualityMedian output sizeReduction from PNG sourceMedian SSIMLowest SSIMMedian Robot timeMedian Assembly duration
JPEG5038 kB93.8%0.9230.8990.48 sec1.17 sec
JPEG7560 kB90.5%0.9510.9380.48 sec1.14 sec
JPEG90107 kB83.2%0.9760.9670.49 sec1.14 sec
WebP5030 kB95.1%0.9300.8980.60 sec1.24 sec
WebP7543 kB93.0%0.9510.9320.48 sec1.21 sec
WebP9094 kB84.9%0.9800.9670.58 sec1.24 sec
AVIF5028 kB95.4%0.9420.9190.99 sec1.71 sec
AVIF7568 kB88.9%0.9780.9591.18 sec1.79 sec
AVIF90148 kB76.4%0.9920.9871.42 sec2.14 sec

24 source images of 768 × 512 pixels with a median size of 620 kB. Reductions are relative to a lossless source, so they are larger than what re-compressing an existing JPEG would yield.

Method

How the benchmark was run

Source files

The optimization study uses 30 files from Wikimedia Commons: for each of JPEG, PNG, GIF, WebP, and SVG, the first six search results inside a fixed file-size band that Commons labels CC0 or public domain. The re-encoding study uses the 24 lossless PNG photographs of the Kodak image set, a common reference set for codec comparisons. The corpus manifest lists every file with its URL, license, dimensions, byte size, and SHA-256 checksum, together with the exact search queries, so the same bytes can be fetched again.

Assemblies

Every measurement is one Assembly that uploads one file and runs one Step. The optimization study varies priority and metadata handling for JPEG, lossy optimization and metadata handling for PNG, and metadata handling for WebP and SVG. Parameters that the Robot ignores for a format are left out, because they would repeat an identical job. The upload Step sets output_meta to false: no Step here reads the metadata of the uploaded file, and extracting it would add to every Assembly duration without changing any result. These are the Assembly Instructions, with the varied parameters shown at one of their values:

{
  "steps": {
    ":original": {
      "robot": "/upload/handle",
      "output_meta": false
    },
    "measured": {
      "robot": "/image/optimize",
      "use": ":original",
      "priority": "compression-ratio",
      "preserve_meta_data": true
    }
  }
}
{
  "steps": {
    ":original": {
      "robot": "/upload/handle",
      "output_meta": false
    },
    "measured": {
      "robot": "/image/resize",
      "use": ":original",
      "format": "webp",
      "quality": 75,
      "strip": true
    }
  }
}

Runs and environment

All Assemblies ran on October 17, 2026 against the production API at api2.transloadit.com, on the same shared machines that serve customer traffic. The full matrix of 294 file and parameter combinations was executed 3 times in sequence, so repeats of one combination are spread over the session, with 3 Assemblies in flight at a time.

Measurements and aggregation

Sizes and timings come from the Assembly Status: the upload size, the result size, the result’s Robot execution and queue time, and the Assembly execution duration. For SSIM, the result of the first run is downloaded, both images are flattened onto white and converted to 8-bit luma, and structural similarity is averaged over 8 × 8 pixel windows at a stride of 4 pixels. Output bytes were identical across the repeated runs of every combination, so only timings vary between repeats. Each table row first takes the median of the repeated runs per file, then the median across files. The 90th percentile is taken over all runs in the row.

Read before generalizing

What this benchmark cannot tell you

  • Six files per format is a small sample, and search results from Wikimedia Commons are not a sample of production traffic. The JPEGs are large, carefully exported photographs and the GIFs are mostly diagrams.
  • Three runs per combination show the spread of timings but are too few for confidence intervals, and all runs happened on a single day.
  • SSIM on luma is a structural metric, not a model of human perception, and it ignores color. Animated GIF and SVG results were not scored at all.
  • The re-encoding study uses small images. Robot time grows with pixel count, so these timings do not describe multi-megapixel photographs.
  • The Assembly Status does not expose machine type or optimizer versions, so they are not part of the dataset. Results describe the production stack on the run date.