Dynamic Compression

Endpoint

GET/fastly_features/dynamic_compression/<filename>

Each file is served at a stable path with its correct Content-Type. Compression is normally gated on content type, so a JSON file served as text/plain or application/octet-stream may not be compressed at all.

Available files

HTML

File	Size	Purpose
html-tiny.html	1.5 KB	Probes the minimum-size threshold. Many configurations skip compression below about 1 KB. If this returns identity while the others are compressed, you have found the cutoff.
html-small.html	17 KB	Templated listing markup, small.
html-medium.html	185 KB	Templated listing markup, mid-size.
html-large.html	1 MB	Templated listing markup at production page scale. The primary comparison target.
html-prose.html	—	Long-form text with much lower structural repetition. Compression level changes affect this differently from templated markup.
html-with-images.html	—	Small HTML page referencing the JPEGs, for a realistic page-plus-assets fetch.
html-inline-jpeg.html	—	A JPEG embedded as a base64 data URI. Base64 inflates binary by roughly 33% and compression claws most of that back, so expect a ratio near 0.77, not 0.10.

Images

File	Type	Purpose
assets/photo-01.jpg	`image/jpeg`	Already entropy-coded, so they act as the incompressible control. Compression ratio should land at about 1.00.
assets/photo-02.jpg	`image/jpeg`
assets/photo-03.jpg	`image/jpeg`

JSON

File	Purpose
json-small.json	Repeated keys compress hard. Confirms that `application/json` is being compressed and gives a second content profile alongside HTML.
json-medium.json
json-large.json
json-medium-pretty.json	Indented variant of `json-medium.json`. Whitespace compresses away almost for free, which makes a good contrast against the minified version.

Try it

Clicking a file above fetches it with whatever Accept-Encoding your browser sends, which is typically gzip, deflate, br. Browsers do not allow a page to override that header, so use the picker below to build a curl command for a specific encoding.

File

Accept-Encoding

The command writes the body to /dev/null and prints the transferred byte count, so you can compare it directly against the identity size.

Reading the results

Verify the identity size is constant first

Fetch each one a few times with Accept-Encoding: identity and confirm the byte count does not move before trusting anything else.

Expect modest gains from level 1 to level 3

Roughly 3% on a small page, 8–13% on larger HTML and JSON, and close to 0% on the tiny file and the JPEGs. Anything dramatically outside that range is worth investigating before you report it.

The JPEGs are a correctness check, not a data point

Gzip can return a JPEG slightly larger than the original because of the gzip envelope on incompressible input. A well-configured edge should skip compression for these entirely. If it is compressing them, that is CPU spent to add bytes.

Watch caching

These files are static, so they cache readily. A cached variant compressed under the old setting will survive a configuration change and quietly serve stale bytes. Check x-cache and age on every response and account for cached variants before comparing runs.

Notes

Compression is negotiated, not guaranteed. A response may come back uncompressed because of a minimum-size threshold, a content-type gate, or an already-compressed payload. Always confirm the content-encoding response header rather than inferring compression from the byte count alone.

Requesting Accept-Encoding: identity gives you the baseline size for every ratio you calculate.
Brotli and gzip respond differently to the same content, so compare each against its own baseline rather than against each other.