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

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

**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 client that bypasses automatic decompression specifically to measure what's genuinely sent — not illustrative numbers. ## 1. Why This Even Matters — A Story First Shipping a box stuffed with packing peanuts around a small item wastes real, physical shipping cost compared to vacuum-sealing the identical item into a fraction of the space before shipping it, with the recipient simply un-sealing it on arrival. HTTP compression is exactly that vacuum-seal step for a response body — verified directly below with a real, dramatic, measured size reduction. ## 2. The Core Idea 📌 **Interview term:** compression middleware reduces the **actual bytes transmitted** over the network, n

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.

nodejs
http
compression
performance

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

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 client that bypasses automatic decompression specifically to measure what's genuinely sent — not illustrative numbers.

1. Why This Even Matters — A Story First

Shipping a box stuffed with packing peanuts around a small item wastes real, physical shipping cost compared to vacuum-sealing the identical item into a fraction of the space before shipping it, with the recipient simply un-sealing it on arrival. HTTP compression is exactly that vacuum-seal step for a response body — verified directly below with a real, dramatic, measured size reduction.

2. The Core Idea

📌 **Interview term

The solution is hidden so you can try first

7 min read · 7 sections

Read the code

JavaScriptA 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%

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.