MGMLaboratory
Back

Menu

01Home
02About Us
03Projects
04Publications
05Member
06Articles
07Contact

Let's Talk

Open in Mail app

Socials

Malang (ID) --:--Privacy PolicyTerms of Service

December 13, 20232 min read

The 150 byte rule for compressing API responsesThe 150 byte rule for compressing API responses

Moving compression from the web server into the application changes who pays for it, and makes one small payload size the deciding factor.

  • Journal
  • Publications

Written by

  • SRShirasaka RenIT & Infrastructure · Student Member

In this article

  1. 01Why application level instead of gzip
  2. 02The threshold that matters

There is a version of API performance work that consists of adding a header and moving on. Turn on gzip at the web server, set Accept-Encoding, and let the infrastructure handle the rest. That works until it does not: a shared host you cannot configure, a proxy that strips the header, or an endpoint where you want compression on one route but not another.

The team behind a 2023 study in the Journal of Information Technology and Computer Science took the other path. They moved compression into the application itself, so the API code decides what happens to each response before it leaves the server.

Cabling in a data centre. Compression shifts load between server and network. Photo: Derrick Coetzee, CC0.
Fig. 01Cabling in a data centre. Compression shifts load between server and network. Photo: Derrick Coetzee, CC0.

01/02

Why application level instead of gzip

Compressing inside the application trades flexibility in one direction for flexibility in another. The server does more work, and the client has to decode the result on its own. In exchange, the behaviour travels with the code instead of depending on an environment somebody else controls.

  • The pipeline runs Zlib on the server through the PHP gzencode function, then Base64 encodes the output.
  • The browser client decodes the Base64 and decompresses with the Pako library in JavaScript.
JSON and XML, the two markup styles most REST payloads use. Diagram: Diego Mariano, CC BY-SA 4.0.
Fig. 02JSON and XML, the two markup styles most REST payloads use. Diagram: Diego Mariano, CC BY-SA 4.0.

02/02

The threshold that matters

The most portable finding is a number. Below about 150 bytes of JSON, compressing makes a response larger rather than smaller. A 68 byte payload arrived as 112 bytes. A 135 byte payload arrived as 144 bytes. The cause is Base64, which encodes every three bytes of Zlib output as four characters.

Above that line the picture flips. Payloads from roughly 12.5 kilobytes upward came back at about a third of their original size, saving up to 66 percent of the transfer volume.

  • Server CPU cost scaled with payload size, reaching 3.269 milliseconds for a 101 kilobyte response.
  • Client side decompression added 0.30 to 8.10 milliseconds, which the authors consider acceptable on modern hardware.

The authors are careful about scope. They measured a single API function from a transport navigation service, applied no caching or pagination, and did not benchmark against native HTTP compression. Those gaps are the obvious next study. For now the takeaway is a habit: pick a size threshold, compress above it, and leave the small responses alone.

Source

  1. Pinandito, A., Kharisma, A.P., Jonemaro, E.M.A. (2023). Architectural Design of Representational State Transfer Application Programming Interface with Application-Level Base64-Encoding and Zlib Data Compression. Journal of Information Technology and Computer Science.

    DOI10.25126/jitecs.202383619 (opens in a new tab)

Next articleWhy Cheap Phones Are Slow at Finding Routes(Keep scrolling)(Read it next)(Loading)