JSON response objects: "pretty" keys and larger response or short keys and smaller response? [closed]

Question

My real-time web app makes ajax requests to obtain JSON econded data responses.

Returned data is usually in the form of an array of objects.

As the array has often a lot of elements (an although data sent is gzipped by the server) in order to keep the response size at minimum I'm keeping the keys in the response very short.

For example instead of using description: I use d:, instead of using width: I use w: and so on...

Doing so reduces the size of the response but, on the client side, very-short non human-readabe keys makes the JavaScript code (that access the object) less readable.

The only solution seem to reparse the response and rebuild the object with pretty keys or replace them in the original object received. But this may hurt the JavaScript code performance resulting in more delay...

Exists a better solution?

---

EDIT:

As Björn Roberg suggested in his comment I've made a comparison:

pretty-response.json       459,809 bytes
 short-response.json       245,881 bytes

pretty-response.json.zip    28,635 bytes
 short-response.json.zip    26,388 bytes

So as the response is compressed by the server the difference is really minimal.

Still, pretty response require the server to compress 450 KB of data, while short response just 240 KB.

Does this impact server performance (or is there a way to measure it) ?

Answer 1

Since you are considering converting the short keys back to long keys on the client side, you are clearly concerned with the bandwidth requirements for the data and not the memory requirements on the client.

I've generated some files containing random data and three keys (description, something and somethingElse). I've also dumped the data through sed to replace those keys with d, s and e.

This results in:

750K   long-keys
457K   short-keys

HTTP has support for compression, and all significant clients support this with gzip. So, what happens if we gzip the files:

187K   10:26 long-keys.gz
179K   10:27 short-keys.gz

There is very little to choose between them, since gzip is rather good at compressing repeated strings.

So, just use HTTP compression and don't worry about munging the data.

gzip is also a really fast algorithm, so the impact it will have on server performance is negligible.