When compressing your JSON API actually pays offWhen compressing your JSON API actually pays off

The design choice that matters is placement. Instead of leaning on the web server Accept-Encoding and gzip layer, the team compressed at the application level. The server runs Zlib through the PHP gzencode function, then Base64 encodes the binary result so the payload stays string safe. The client reverses both steps, decompressing with the Pako library in JavaScript.

That approach keeps working even when the web server cannot be reconfigured for compression. It also lets the API decide, payload by payload, whether compressing is worth the effort.

Large payloads compress well. For JSON between roughly 12.5 and 101 kilobytes, the compressed and encoded output settled at about 33 percent of the original size. That is a bandwidth saving of up to 66 percent, which is the headline claim the authors set out to test.

• Server CPU cost rose from 0.064 milliseconds on a 68 byte payload to 3.269 milliseconds on a 101 kilobyte payload.
• Memory overhead stayed under 2.62 percent, which the authors describe as negligible.

Small payloads are where intuition breaks. A 68 byte response grew to 112 bytes after compression and encoding. A 135 byte response grew to 144 bytes. Base64 expands the binary that Zlib produces, and below roughly 150 bytes that expansion costs more than the compression saves.

A Mann-Whitney U test on memory usage returned a p value of 0.0000022, so the overhead is statistically real but minor. The practical rule fits in a sentence: compress the big responses, leave the tiny ones alone.