A JSON File 19% Smaller That Ships Only 3% Smaller — Measuring Catalog Payloads Against gzip

Why Key Shortening Does Almost Nothing

gzip (DEFLATE) replaces any byte sequence that already appeared within the previous 32KB window with a short back-reference — a distance and a length. In an array of objects, a key fragment like "imageUrl":"https://cdn... repeats 20,000 times, and repetition of this kind is exactly what gzip handles best. From the second occurrence on, each key costs only a few bits.

In other words, your key names are already nearly free. Shortening them turns a few bits into a few bits, and the shipped size barely moves. That is why variant B removes 1.34MB of raw bytes yet saves only about 30KB on the wire.

Until I ran this, I had filed key shortening under "unglamorous but reliable." It is actually a trade of readability and debuggability for 3%. At least for my catalog, that trade does not clear.

The Columnar Transpose — gzip Reaching Brotli Territory

Variant D merely transposes the array of objects into one array per field. Not a single byte of data is removed. Yet it ships 26.8% smaller — the strongest single technique in this test.

The reason is how the gzip window gets used. In row order, similar values — the same category names, numbers in the same range, timestamps in the same format — sit far apart, separated by all the other fields. Transposed into columns, similar values become neighbors, and back-references keep hitting at short distances. It is a layout that meets the compressor halfway.

The absolute numbers held a surprise. Columnar gzip(6) lands at 691,065 bytes — almost exactly the 691,526 bytes you get from compressing the baseline with Brotli quality 11. A pure layout change took plain gzip to Brotli-grade output. If your delivery path cannot serve Brotli, the payload itself can make up the difference.

I also timed parsing: median of 11 runs of JSON.parse gives 37.2ms for A and 19.8ms for D. The columnar form needs to be rehydrated into objects on the device, but that step measured 12.7ms, for a total of 32.5ms — still faster than parsing the row-ordered JSON directly. That inverted my expectation as well. Parse time tracks raw size closely, so the smaller columnar payload wins even with the extra step.

Move URLs Out Into a Template

Removing URLs (variant C) ships 21.1% smaller — far better than short keys, but a long way down from its 40.5% raw reduction. URLs share long common prefixes like https://cdn.example.com/wallpapers/, which makes them some of the most compressible data in the file.

Still, if every URL can be rebuilt mechanically from a path convention ({category}/{id}/original.jpg), moving them out is worth it. Variant E — columnar plus URL removal — ships at 534,016 bytes, a 43.4% cut. Decompression time drops from 12.9ms to 4.8ms, and JSON.parse takes 11.9ms.

One caution: templating URLs bakes your delivery convention into client code. If you later restructure CDN paths, old app versions will keep building URLs the old way. Whether you can live with that constraint decides whether C and E are available to you. My own approach is to carry a schema version in the payload, so the server can fall back to serving full URLs to older clients if the convention ever changes.

The Paging Tax Is 2.9%

I also measured the worry that splitting hurts compression. Splitting the 20,000 items into 40 pages of 500 and gzipping each page separately totals 970,897 bytes, against 943,796 bytes for the single blob: a 2.9% tax.

The smaller window does cost something, but that is the whole bill. Fetching only the first page for initial render and loading the rest in the background costs almost nothing in total size. The state-management side of paged fetching is a separate topic I covered in cursor pagination and refetch state design; here I only wanted the size numbers on record.

The Client Side — Rehydration With a Schema Guard

Here is the receiving end for a Rork-generated Expo (React Native) app: fetching, validating, rehydrating, and URL building in one function. It checks the schema version v first and throws on anything unexpected, so the caller can fall back to a cached catalog.

const CDN = 'https://cdn.example.com';
const CATALOG_SCHEMA_VERSION = 2;
 
type WallpaperItem = {
  id: number; title: string; category: string; tags: string[];
  width: number; height: number; fileSize: number;
  premium: boolean; createdAt: string; sortScore: number;
  imageUrl: string; thumbUrl: string;
};
 
export async function fetchCatalog(url: string, timeoutMs = 10000): Promise<WallpaperItem[]> {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  try {
    // fetch decompresses gzip / Brotli transparently; no manual Accept-Encoding needed
    const res = await fetch(url, { signal: controller.signal });
    if (!res.ok) throw new Error(`catalog fetch failed: ${res.status}`);
    const cols = await res.json();
 
    // Schema guard. A columnar payload can be structurally broken yet still
    // "readable", so verify the version and every column's presence and length
    if (cols?.v !== CATALOG_SCHEMA_VERSION || !Array.isArray(cols.id)) {
      throw new Error('unexpected catalog schema');
    }
    const n = cols.id.length;
    for (const k of ['title','category','tags','width','height','fileSize','premium','createdAt','sortScore']) {
      if (!Array.isArray(cols[k]) || cols[k].length !== n) {
        throw new Error(`catalog column broken: ${k}`);
      }
    }
 
    // Rehydrate + rebuild URLs (measured at 12.7ms for 20,000 items)
    const items: WallpaperItem[] = new Array(n);
    for (let i = 0; i < n; i++) {
      const id = cols.id[i];
      const category = cols.category[i];
      items[i] = {
        id, category,
        title: cols.title[i], tags: cols.tags[i],
        width: cols.width[i], height: cols.height[i],
        fileSize: cols.fileSize[i], premium: cols.premium[i],
        createdAt: cols.createdAt[i], sortScore: cols.sortScore[i],
        imageUrl: `${CDN}/wallpapers/${category}/${id}/original.jpg`,
        thumbUrl: `${CDN}/wallpapers/${category}/${id}/thumb.jpg`,
      };
    }
    return items;
  } finally {
    clearTimeout(timer);
  }
}

One operational note for the serving side: Brotli quality 11 took 14.4 seconds to compress the 7MB input (9.5 seconds even for the columnar variant). Do not compress per request — generate .json.br and .json.gz at catalog build time and serve them statically. Decompression, by contrast, is cheap: 12.9ms for gzip on the device side.

The Order I Now Follow

Based on these measurements, this is the order in which I make the calls:

1. Confirm compression on the delivery path first. The gap between uncompressed 7MB and gzipped 944KB (−86.6%) dwarfs everything else in this article. Check your CDN settings and the content-encoding response header before touching the payload
2. Transpose to columnar. A 26.8% cut without deleting any data, plus faster parsing. The cost is a rehydration function and a schema guard
3. Remove derivable fields. Anything rebuildable from a convention, like URLs, can move out — but always carry a schema version so you can retreat from the convention later
4. Paginate freely. The size tax is 2.9%. Fetch what the first screen needs and defer the rest
5. Skip key shortening. Trading readability for 3.2% is not a deal worth taking, at least not for catalog delivery

One last caveat: a lighter catalog changes nothing if the image fetching behind it stays heavy. For that side of the pipeline, I keep operational notes in measuring and capping the image cache in a wallpaper app.

If you take one thing from this piece, let it be the habit of measuring formats A, D, and E on your own catalog. Your numbers will differ, but the shape of the result — raw reduction and shipped reduction are different things — will almost certainly hold. I hope these tables save you the afternoon it took me to build them.