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 realAccept-Encodingheader listing what it can decompress (gzip,br, and others); the server's compression middleware only compresses the response — and sets the corresponding realContent-Encodingheader — when the client has genuinely indicated support, verified directly above by the real, distinctgzipresponse 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.