Challenge 3: Why Compressing JPEGs Wastes CPU, and How
SetEnvIfNoCase Prevents It — Solution Walkthrough

Why compressing JPEGs wastes CPU:

Gzip-style compression (what mod_deflate applies) works by finding
and eliminating redundant, repeated patterns in the data. Text-based
formats like HTML, CSS, and JavaScript are full of exactly that kind
of repetition -- repeated tags, whitespace, common keywords -- so
compressing them meaningfully shrinks the response. A JPEG file is
already compressed by its own format at the time it's saved; the
data inside it is already close to maximally dense, with very little
of the redundant structure gzip depends on to find savings. Running
mod_deflate against it still costs real CPU time scanning the file
for patterns to compress, but finds little or nothing worth
compressing -- and occasionally the compressed output ends up
slightly LARGER than the original, since gzip adds its own small
amount of format overhead.

How SetEnvIfNoCase prevents it:

The line SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|zip|gz|mp4)$
no-gzip checks the request's URI against that list of file
extensions, and if it matches, sets an environment variable named
no-gzip for that request. mod_deflate itself checks for that
variable before compressing a response, and skips compression
entirely whenever it's set -- so requests for .jpg, .png, .zip, and
similar already-compressed files are excluded from the DEFLATE filter
before any compression work is even attempted, rather than being
compressed and then discarded.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands WHY compression
helps text but not already-compressed binary formats -- not just that
it does -- and can trace exactly how the SetEnvIfNoCase mechanism
prevents the wasted work at the source rather than after the fact.