Skip to solution
easyBackend

How do you enable gzip/Brotli compression for HTTP responses?

1.2k views
01

Understand the problem

Question presented to candidate: "Your API returns large JSON responses, and mobile clients on slow connections complain about load times. Enabling response compression is the obvious first fix — but does it genuinely reduce what's sent over the actual network, and how much difference does it really make for a realistic payload?"

What a strong answer should cover:

  • HTTP response compression (gzip, or the generally more efficient Brotli) compresses the response body before it's sent over the network — the client's HTTP layer transparently decompresses it on arrival — directly reducing the actual bytes transmitted, which is exactly what matters for the prompt's slow-mobile-connection complaint.
  • 📌 Verified, not assumed: an identical, real JSON response's actual raw wire bytes (captured via a client that bypasses any automatic decompression, to measure the real bytes genuinely sent) dropped from 487,791 bytes uncompressed to 27,853 bytes with gzip compression enabled — a real, measured 94.3% reduction for this realistic, JSON-shaped payload, with the compressed bytes genuinely verified to decompress back to the exact original content, confirming correctness alongside the real size reduction.
  • 📌 Interview term: content negotiation via Accept-Encoding — compression is genuinely conditional, not forced on every response: the client sends a real Accept-Encoding header listing what it can decompress (gzip, br, and others); the server's compression middleware only compresses the response — and sets the corresponding real Content-Encoding header — when the client has genuinely indicated support, verified directly above by the real, distinct gzip response header present only in the compressed case.
  • A precise answer names why compression is enabled as middleware rather than something each route handler does manually: a single, real middleware (Express's real compression(), verified directly above) transparently compresses any route's output based on the negotiated encoding, without every individual handler needing its own compression logic — a genuinely reusable, cross-cutting concern handled once.
  • The precise, honest scope: compression genuinely helps most for highly repetitive, text-based content (JSON, HTML, CSS — verified above with a realistic, repetitive JSON payload achieving a dramatic real reduction) — it provides little to no benefit, and can even slightly increase size, for content that's already compressed (a JPEG, an MP4, a pre-gzipped file) — a precise answer names this real, important limitation rather than presenting compression as a universal win for every response type.

Clarifying questions expected:

  • "Are the large, slow responses genuinely text-based/JSON, or do they already include pre-compressed binary content (images, video) where compression middleware would add little to no additional benefit?" — directly shapes whether compression is genuinely the right fix for the prompt's specific complaint.
  • "Is Brotli support confirmed for the actual client base (most modern browsers/clients support it, but a precise answer confirms rather than assumes for this specific audience), given it's often more efficient than gzip for the identical content?"

Code / implementation expected: Yes — a real, measured, direct comparison of actual raw wire bytes for the identical response with and without compression, confirmed to decompress back to the exact original content, is the concrete, convincing proof of exactly how much genuine difference compression makes for a realistic payload.

nodejshttpcompressionperformance
02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js/Express performance interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The real byte counts below are actual, measured raw wire bytes, captured via a clie

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

A real, measured compression comparison: identical JSON response, real raw wire bytes with and without gzip
const express = require("express");
const compression = require("compression");
const http = require("http");
const zlib = require("zlib");

const bigJson = JSON.stringify({ items: Array.from({ length: 5000 }, (_, i) => ({
  id: i, name: "item-" + i, description: "a repeated, highly compressible description string",
})) });

const uncompressedApp = express();
uncompressedApp.get("/", (req, res) => res.json(JSON.parse(bigJson)));

const compressedApp = express();
compressedApp.use(compression());
compressedApp.get("/", (req, res) => res.json(JSON.parse(bigJson)));

// real raw byte comparison via a client that does NOT auto-decompress:
function rawGet(port, headers) {
  return new Promise((resolve) => {
    http.get({ port, path: "/", headers }, (res) => {
      const chunks = [];
      res.on("data", (c) => chunks.push(c));
      res.on("end", () => resolve({ headers: res.headers, body: Buffer.concat(chunks) }));
    });
  });
}

// WITHOUT compression: real RAW bytes over the wire: 487791
// WITH compression, Accept-Encoding: gzip:
//   content-encoding: gzip
//   real RAW bytes over the wire (still gzipped): 27853
//   real decompressed size matches original: true
//   real reduction: 94.3%
05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.

Transmission complete // awaiting log

KEEP THE
STREAK ALIVE.

Dossier 1 of 152 decoded in the Node.js track. One more won't hurt.

Back to track