How to Use This Tool
Paste a response and every field is measured. The share column is the one to read — it tells you where the effort belongs.
Measuring the right thing
Each field is measured as the bytes it contributes to the serialised document: the key name, the quotes, the colon, the value and the separating comma. That is what actually travels.
Fields inside arrays are aggregated across every occurrence, which matters enormously. A field costing 40 bytes per item is 40 KB across a thousand-item response, and looking at one item hides that completely.
The usual culprits
- Base64 blobs. An embedded thumbnail or file is almost always the largest single thing, and base64 adds exactly 33% to whatever it encodes. Serving a URL instead removes the field and the overhead together, and lets the browser cache the image separately.
- Long free text returned in a list view that only displays the first line.
- Fields nobody reads. Internal identifiers, audit timestamps, denormalised copies. The cheapest optimisation available is deleting them, and the reason it does not happen is that nobody is sure who consumes them.
- Deep nesting, where the structural characters start to rival the data.
Key names, and why gzip is not the whole answer
Key names repeat once per item. A field called customerShippingAddressLine1 spends 30
bytes on its name alone, which is 300 KB across a 10,000-item response before any value is included.
Gzip handles this well — repeated strings are exactly what it compresses — so the wire cost is far smaller than the raw figure suggests. The measurement here includes real gzip output rather than an estimate, so you can see the difference for your own data.
What gzip does not remove:
- Parse time. The document is decompressed before it is parsed, so the parser still processes every byte.
- Memory. The in-memory representation is larger than the JSON, not smaller.
- Cost on constrained clients, where decompression itself is measurable.
So compare the raw and gzipped figures before acting. If gzip already removes most of a field's cost, renaming it buys little; if a field is large because its values are large and varied, gzip cannot help and removing it is the only option.
What to do with the answer
In rough order of payoff:
- Remove fields the client does not use. Free, and usually blocked by uncertainty rather than difficulty.
- Move blobs out of the payload and reference them by URL.
- Paginate, or let the client request the fields it wants.
- Truncate long text in list views and fetch it in full on demand.
- Shorten key names — last, because it costs readability and gzip has usually handled it already.
