# Should you compress images before your CDN re-encodes them? Measured through Next.js, wsrv.nl and Photon **Author:** SJ | **Published:** 2026-11-03 | **Tags:** WebP, JPEG | **URL:** https://www.iminify.com/blog/31-should-you-compress-images-before-your-cdn-re-encodes-them-measured-through-nextjs-wsrvnl-and-photon --- The Fjord, one of our five test photographs, is an 852,461-byte JPEG, the master every score below is measured against. Iminify's Smart level makes it a 568,598-byte JPEG. We sent both through Next.js 16.4.3's image optimizer at its default, WebP at quality 75. Next's WebP of the master weighed 321,790 bytes and scored 66.98 against the master on [SSIMULACRA 2](https://www.iminify.com/blog/1-ssimulacra-2-scores-in-practice-what-50-70-and-90-cost-in-kilobytes#the-ssimulacra-2-scale-is-a-set-of-viewing-tests), where 100 means no difference from the master. Its WebP of the Smart file weighed 314,578 bytes and scored 64.30: 2.2 percent fewer bytes for 2.7 points. Should you compress before a CDN or optimizer re-encodes your image? In our tests, on five JPEG photographs through Next and wsrv.nl, only losslessly. A lossless repack, which made our uploads 2.4 to 5.6 percent smaller, changed nothing in 80 of 80 Next responses. And in 40 of 40 comparisons at no more bytes, asking Next for a lower quality setting scored higher than the lossy first pass. If nothing re-encodes after you, compress first. ## A lossless repack changed nothing Next or wsrv.nl sent Iminify's [Lossless level](https://www.iminify.com/compress-jpeg?level=lossless) rewrites how a JPEG's coefficients are packed and leaves the pixels alone ([25 files checked](https://www.iminify.com/blog/24-how-much-does-lossless-jpeg-compression-save-25-files-every-pixel-checked#every-pixel-came-back-the-same) in an earlier post). On our five photographs it saved 2.4 to 5.6 percent of the master, and every file scored 100.00 against it. Through Next, the five Lossless files produced the same bytes as the five masters: 80 of 80 responses had the same SHA-256. That is two runs of 40 requests, each for five photographs at two widths, as WebP 75 and JPEG 75 under Next's defaults and as WebP 75 and WebP 90 with `qualities: [75, 90]`. (JPEG is Next's answer to a browser that lists neither WebP nor AVIF.) wsrv.nl, a public image proxy, did the same, as JPEG and as WebP, on all five photographs. ## At 1800 px and WebP 75, a Smart first pass trims 2 to 13 percent off what Next sends and costs 3 to 8 points Next's default WebP 75, at the photographs' own 1800 pixels, each cell the median of the five photographs. Smart is Iminify's default level and Ultra its most aggressive: | Upload | Upload size | Delivered size | Score against the master | |---|---|---|---| | Master | 396,520 B | 73,188 B | 66.98 | | Lossless | 383,500 B | 73,188 B | 66.98 | | Smart | 128,292 B | 67,964 B | 61.27 | | Ultra | 76,903 B | 62,706 B | 55.30 | Per photograph, Smart's delivered file was 86.7 to 97.8 percent of the master's delivered file and scored 2.7 to 8.2 points lower. Ultra's was 82.2 to 92.8 percent and scored 8.1 to 14.5 lower. [Cloudflare's Polish compression page](https://developers.cloudflare.com/images/polish/compression/) (updated 21 April 2026) says: "Re-encoding of files that are already optimized reduces their quality more than it reduces their file size." Next's second pass took 27 to 48 percent off the bytes of the Smart uploads and 8.6 to 22.2 points off their scores, which are different units. ## Asking Next for a lower quality scored higher in all 40 comparisons We asked Next for each master at twenty qualities from 50 to 90. For every lossy route (a Smart or Ultra upload and one Next setting) we took the highest of those qualities whose WebP of the master was no bigger than the route's file, and compared scores. Next's WebP of the master scored higher in all 40 comparisons (Smart or Ultra, delivered at WebP 75 or 90, two widths, five photographs), by 0.12 to 13.88 points, median 4.06. On the Fjord, the Smart route's 314,578 bytes scored 64.30. Next's WebP of the master at quality 72 was 309,732 bytes and scored 65.55. ![Scatter chart for the Fjord at 1800 px, score against bytes. The master through Next at twenty qualities runs from 243,122 bytes at 57.4 to 590,444 bytes at 83.1. The four lossy-first routes, Smart or Ultra then WebP 75 or 90, all sit below that curve, from 55.8 at 289,188 bytes to 77.3 at 562,868 bytes.](https://iminify.nbg1.your-objectstorage.com/blog/images/wMGxrzjAlQ2fgHHhpXnxeWBcmmmWKlbY.webp) | Median gain in points, by route | At 1800 px | At 1080 px | |---|---|---| | Smart, then WebP 75 | +2.36 | +0.93 | | Ultra, then WebP 75 | +8.20 | +2.55 | | Smart, then WebP 90 | +5.46 | +1.61 | | Ultra, then WebP 90 | +12.33 | +5.87 | Next only serves the qualities in its [`qualities` list](https://nextjs.org/docs/app/api-reference/components/image#qualities), 75 by default. Listing a lower one is how you ask Next for fewer bytes. The same comparison for wsrv.nl's WebP, on the ten Smart and Ultra uploads it covers, was won by the master's WebP in 10 of 10 cases, by 1.22 to 10.28 points. Its WebP of a master matched Next's byte for byte on each of the ten photograph and quality pairs those cases needed, so Next's sweep stands in for wsrv.nl's. ## A second pass can hand you a file bigger than the one you uploaded Delivered size as a percent of the upload, at 1800 px, over the five photographs: | Optimizer | Smart upload | Ultra upload | |---|---|---| | Next, WebP 90 | 99 to 152 (bigger on 4 of 5) | 151 to 172 (5 of 5) | | wsrv.nl, JPEG at its default quality 80 | 79 to 122 (bigger on 3 of 5) | 115 to 133 (5 of 5) | Our [WebP post](https://www.iminify.com/blog/28-why-is-my-webp-bigger-than-the-jpg-measured-on-40-jpegs-and-4-pngs#a-jpeg-saved-at-80-turns-into-a-bigger-webp-from-about-quality-90) found that a JPEG saved at 80 gives a bigger WebP from about quality 90. ## What wsrv.nl and Photon did to the same files wsrv.nl [defaults to quality 80](https://wsrv.nl/docs/format). Asked for WebP with `output=webp`, it delivered the Smart uploads at 75 to 97 percent of its WebP of the master and 3.6 to 8.8 points lower. [Photon](https://developer.wordpress.com/docs/developer-tools/site-accelerator-api/), Jetpack's image CDN, answers a browser that lists WebP differently from one that doesn't. Asked for a JPEG, it returned the Lossless, Smart and Ultra files byte for byte (15 of 15) and the masters at 95.5 to 99.0 percent of their size, still scoring 100.00. Asked for WebP by a browser that lists it, as Chrome does, Photon matched wsrv.nl byte for byte on the five masters and the five Lossless files. For the lossy uploads it sent smaller files than wsrv.nl in nine of ten cases; the exception is the Fjord's Smart file. The Fjord's Ultra file came back as 231,974 bytes against wsrv.nl's 344,010, and scored 50.32 against 59.20. Photon's WebPs of the five Smart uploads weighed 38.5 to 97.1 percent of its WebP of the master and scored 3.6 to 23.0 points lower. ## Cloudflare and Cloudinary: documented, not tested Polish is [not on the Free plan](https://developers.cloudflare.com/images/polish/). Its [compression page](https://developers.cloudflare.com/images/polish/compression/) recommends origin JPEGs at quality 80 to 90, because blocky low-quality ones make bigger WebPs, and says "It does not make sense to apply lossy optimizations twice to images, because quality degradation will be larger than the savings in file size." We didn't run it: it needs a paid zone and a setting on a live site. Cloudinary's [q_auto documentation](https://cloudinary.com/documentation/image_optimization) lists four presets and says nothing about sources that are already compressed. Its demo cloud answered fetches of six of our files with `x-cld-error: ACL deny`, so we sent none through it. ## What to upload 1. If something re-encodes after you, upload the master or its [lossless repack](https://www.iminify.com/compress-jpeg?level=lossless) and set the quality at the optimizer. Squarespace, for one, [encodes its copies itself](https://www.iminify.com/blog/22-does-squarespace-compress-images-what-it-sent-chrome-for-621-images#should-you-compress-before-uploading). 2. If nothing does, compress first: [Smart](https://www.iminify.com/compress-jpeg) took the Fjord from 852,461 to 568,598 bytes, and Photon's JPEG path delivered it as it came. A browser that lists WebP gets Photon's second pass instead. 3. To find out which one you have, fetch your image through your site and compare it with the file you uploaded, sending the Accept header a current browser sends. Photon answers it; wsrv.nl ignores it. Our check on wsrv.nl: ```bash curl -sf -o upload.jpg https://www.iminify.com/image/showcase/photo-landscape/smart.jpg curl -sf -o delivered.jpg -H 'Accept: image/avif,image/webp,image/*,*/*;q=0.8' 'https://wsrv.nl/?url=https://www.iminify.com/image/showcase/photo-landscape/smart.jpg' wc -c upload.jpg delivered.jpg ``` Different sizes mean something rewrote the file: here 568,598 bytes became 449,828. A score against your original shows whether it lost quality. ## How we measured The photographs are the five JPEG masters of [our corpus](https://www.iminify.com/blog/1-ssimulacra-2-scores-in-practice-what-50-70-and-90-cost-in-kilobytes#run-it-yourself), 1800x1200, saved at quality 92, so every score says how far a file is from that JPEG, not from a camera original. The Lossless, Smart and Ultra files are Iminify's `jpg` output of each, the files its showcase serves; we re-ran all 15 through the API on 1 November 2026 and got identical SHA-256 on 15 of 15. Next ran 16.4.3 in a container on sharp 0.35.5, a copy of the harness of our [Next.js post](https://www.iminify.com/blog/26-what-image-quality-does-nextjs-ship-webp-75-avif-47-if-you-list-it-and-by-default-a-90-becomes-75#how-we-measured): its answers for the five masters matched that post's outputs on 40 of 40 SHA-256, and a second run of all 160 requests (40 for each of the four uploads) returned identical bytes. Quality 90 came from `qualities: [75, 90]`. Next accepts at most twenty qualities, so the sweep used 50, 55, 58, 60, 62, 64, 66, 68, 70, 72, 74, 75, 76, 78, 80, 82, 84, 86, 88 and 90. We scored every answer with `ssimulacra2` from libjxl v0.12.0 after decoding with `djpeg` or `dwebp`, against the master resized by sharp the way Next does, written losslessly. wsrv.nl and Photon answered curl requests on 1 November 2026 at the photographs' own size, and each file is scored against the master. We tested five photographs, WebP and JPEG, not AVIF.