Gzip levels 1, 6 and 9 on mixed web payloads
Processing time and output-size measurements for three common gzip levels on the same mixed JSON and text fixture.
The choice this benchmark informs
How much additional CPU time buys how many additional bytes when gzip level rises from 1 to 6 or 9?
Compression settings are frequently copied from server examples without measuring whether the extra work matters for the actual response mix.
For dynamic responses, compression CPU can sit on the request path. For precompressed static assets, build-time cost may be nearly irrelevant.
Result and trade-off
What this run shows: Level 1 minimized compression time; higher levels must justify their additional CPU with enough reusable byte savings. The slowest-to-fastest median spread was 554.18% on the measured host.
| Variant | Median | Middle 50% | Operations/s | Additional measure |
|---|---|---|---|---|
| Level 1Fastest | 380.10 µs | 376.60 µs–394.07 µs | 2,631 | 9,532 output bytes |
| Level 6 | 927.82 µs | 914.78 µs–933.68 µs | 1,078 | 6,784 output bytes |
| Level 9 | 2.49 ms | 2.46 ms–2.61 ms | 402 | 6,369 output bytes |
Timing and extra output metrics are calculated directly from the downloadable samples.
How to interpret the difference
The fastest level is not automatically the right level, and the smallest file is not automatically the right file. The useful comparison is incremental CPU cost per byte saved.
A middle level is often a sensible dynamic-response baseline when it captures most of the size reduction without paying the highest compression cost. Static assets can be evaluated separately because they can be compressed once and reused many times.
Decision rules
- Separate dynamic-response compression policy from precompressed static-asset policy.
- Evaluate Brotli or CDN edge compression separately rather than assuming gzip results transfer directly.
- Re-run with representative HTML, CSS, JavaScript and API payloads from the real application.
Fixture and measurement design
Higher levels should usually reduce output size at increasing CPU cost, with diminishing returns near level 9 for this payload.
- The fixture combines nested JSON and repeated prose-like text so it is compressible without being a single repeated character stream.
- Every variant receives identical bytes and returns a complete gzip stream.
- Output size is recorded alongside median time; decompression cost and network transfer are not included.
Open measured environment
- Measurement run
- 2026-07-22T15:23:56+00:00
- PHP
- 8.4.23 (cli)
- Operating system
- Linux 4.18.0-553.85.1.el8_10.x86_64
- Architecture
- x86_64
- Processor
- AMD EPYC-Rome Processor
- Reported host memory
- 15.02 GiB host total
- CLI OPcache
- 0
- PHP memory limit
- 1024M
- Loaded study extensions
- json, openssl, zlib, mbstring, pdo_sqlite
- Timing clock
- hrtime(true)
- Measured rounds
- 7
Where this result stops
- The fixture is synthetic and cannot represent every entropy profile.
- The benchmark does not measure client decompression, edge-cache hit rate or actual transfer time.
Primary documentation
These primary sources define the formats and APIs involved. They should be read alongside the measured host data, not replaced by it.