Compression
Two different things get called compression, and they work differently. Text responses are compressed for you, automatically, based on what the client says it accepts. Images are not — you ask for a format on the delivery URL and get exactly what you asked for.
Text responses
Points of presence compress text responses with Brotli or Gzip. Those are the two algorithms available; there is no third.
| Algorithm | Accept-Encoding token | Notes |
|---|---|---|
| Brotli | br | Preferred. Better ratio on text, and every current browser supports it. |
| Gzip | gzip | Fallback for clients that do not advertise Brotli. |
The client picks by advertising what it accepts, and the edge chooses the best one on that list:
curl -sI -H 'Accept-Encoding: br, gzip' https://shop.example.com/ | grep -i content-encoding
content-encoding: br
A client that sends no Accept-Encoding, or sends identity, gets the response uncompressed. Small responses and already-compressed content — images, video, archives — are not compressed again, because there is nothing to gain.
You do not enable this and there is nothing to configure. Most HTTP clients and every browser advertise br, gzip by default, so you get compression without doing anything; a client that sets Accept-Encoding: identity explicitly is opting out.
api.revenexx.com are answered by the origin, which does not compress. If transfer size on API responses matters to you — a bulk export, a large product list — request fewer fields or page more aggressively rather than relying on compression. See Pagination & filtering.Images
Image compression is not applied by default. A file you upload is stored and served as you uploaded it — the original stays the source of truth. You get a smaller variant by asking for one on the delivery URL, and the result is cached at the point of presence per set of parameters — see Content delivery.
https://shop.example.com/cdn/photos/sunset.png?w=1800&fm=webp&q=90
fm selects the output format and q sets the quality:
| Format | fm value | Notes |
|---|---|---|
| WebP | webp | The usual choice. Good ratio, universal browser support. |
| AVIF | avif | Smaller than WebP at the same quality, at the cost of more encode time. |
| JPEG | jpg | Lossy fallback. |
| PNG | png | Lossless — use it when you need transparency without artefacts. |
Request the format the client can actually display. If you are serving a <picture> element, ask for avif in one source and webp in the next and let the browser choose; if you are generating a URL for something that is not a browser, jpg is the safe answer.
The full parameter list — sizing, cropping, gravity, quality — is in Serve and transform images.
Related
- Serve and transform images — every transform parameter
- Content delivery — where transformed variants get cached
- Caching — the headers that tell you what was served from where