Challenge 2: Compressing .jpg and .mp4 Files — Solution Walkthrough

Why this is unlikely to help:

JPEG images and MP4 video are already stored in compressed binary
formats — their own encoding has already squeezed out the vast
majority of redundant data a general-purpose compressor like gzip
looks for. Per this chapter's own warning box, running gzip against
content that's already compressed finds little or no further
redundancy to remove, so the resulting file is barely smaller, if at
all, than the original.

Why it can actually make things slightly worse:

Compression still costs real CPU time on the server for every request
it's applied to, regardless of whether it actually shrinks the file
meaningfully. Spending that CPU time on .jpg/.mp4 files gets little or
nothing back in return, while the same CPU could otherwise be used
serving other requests, or gzip's own attempt to compress
already-dense binary data can occasionally result in an output that's
marginally larger than the original, due to the compression format's
own overhead.

The better approach:

Restrict gzip_types (or the equivalent on another server) to
genuinely compressible content types — text, CSS, JavaScript, HTML,
JSON, and similar — leaving already-compressed binary formats like
images and video untouched, exactly the distinction this chapter's own
compression section draws.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete,
realistic misconfiguration — correctly identifying "no meaningful size
reduction, but a real CPU cost every time" as the actual mechanism
behind why blanket-compressing everything is a bad default, not just a
vague "it's not a good idea."