Why compression matters for page speed
Text-based responses (HTML, CSS, JavaScript) typically compress to a fraction of their original size, so enabling gzip or Brotli compression on the server is one of the simplest ways to cut load times without touching the actual content. This sends two requests - one asking for compression, one asking for the raw response - and compares the transferred sizes to confirm whether your server is actually taking advantage of it.
Gzip versus Brotli
Both are compression algorithms supported by modern browsers - Brotli generally compresses slightly better than gzip, but gzip has broader, longer-standing server support. Either is a meaningful improvement over no compression at all, and many modern server setups support both, serving whichever the requesting browser indicates it accepts.
Why checking both compressed and uncompressed size matters
Seeing both numbers side by side makes the actual savings concrete - a page that's, say, 300KB uncompressed but transfers at 80KB compressed shows a real, substantial reduction in what visitors actually have to download, which translates directly into faster load times, especially on slower connections.
Enabling compression if it's missing
It's typically a one-line configuration change on the server - enabling mod_deflate or mod_brotli on Apache, or gzip/brotli directives on nginx - check your hosting control panel or server configuration file, since the exact steps depend on your specific hosting setup and which web server software you're running.