How fast can your browser compress and decompress data? Four fixed datasets — plain text, structured JSON, semi-random binary data and a synthetic photo — each compressed and then decompressed with gzip or JPEG, the same amount of work for every visitor. Lower total time is better.
Lossless data compression is one of the quiet workhorses of computing — every downloaded update, every web page transferred over HTTPS, every archive a user double-clicks relies on an algorithm finding and removing redundancy from data fast enough that nobody notices it happening. The DEFLATE algorithm behind gzip and ZIP, published in the early 1990s, is still the most widely deployed compression format on the internet precisely because it strikes a practical balance between compression ratio and speed rather than chasing the best possible ratio at any cost.
This benchmark exercises that balance directly: three fixed datasets — a block of generated pseudo-English text, a structured array of JSON records, and a semi-random binary buffer with only mild internal repetition — are each compressed and then decompressed several times in a row using the browser's own native gzip implementation. A fourth dataset, a synthetic photo-like image generated the same deterministic way, is instead run through the browser's own JPEG encoder and decoder — a lossy, DCT-based codec built for photographic detail rather than gzip's byte-level redundancy, so it stresses a different part of the browser entirely. Every dataset is generated from a seeded pseudorandom source, so the input is identical for every visitor.
The score is the combined wall-clock time in milliseconds for all eight steps, timed with performance.now() — lower is better. The table above fills in with each step's own time as the run reaches it, so a device that's fast at one codec but slow at the other shows up clearly rather than being hidden inside one combined number.