HTTP Compression: Why Downloads Can Be Smaller Than Decoded Content

A JavaScript file can be large in an editor yet require fewer bytes to travel over the network. HTTP compression is one reason: the server sends an encoded representation and the browser decompresses it. Understanding this distinction helps interpret performance measurements without assuming that enabling compression automatically makes a website fast.

1. Network compression preserves the content

gzip and Brotli provide lossless compression for web content. The browser reconstructs the content for processing rather than removing JavaScript functionality. Compression also differs from minification: minification changes how code is represented, while HTTP compression changes its transmitted form.

MDN's Content-Encoding reference explains how this header identifies the encoding applied to content. Content-Type still describes the content format, such as HTML or JSON.

2. Distinguish three headers

This is an illustration, not a measurement from a particular website:

Request:
Accept-Encoding: gzip, br

Response:
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Vary: Accept-Encoding

The token br identifies Brotli. The client's list does not instruct the server to choose the first algorithm. Accept-Encoding participates in negotiation, while server capabilities and configuration also influence the result.

3. Not every resource benefits from more compression

HTML, CSS, JavaScript and JSON are useful candidates to measure. JPEG and ZIP are already compressed; additional compression may save little or even increase size. For tiny responses, consider processing overhead against the bytes saved.

There is no universal saving ratio. Repetitive content differs from data with little redundancy. A hypothetical reduction from 500 KB to 120 KB illustrates a comparison, not a promise about every file.

4. Read browser measurements in context

1. Open DevTools Network and reload a page you are authorized to inspect.
2. Select an HTML, CSS or JavaScript request and inspect request and response headers.
3. Check whether the response has Content-Encoding.
4. Distinguish transferred size from decoded content size; labels and display details vary by tool.
5. Record status, cache source and network conditions for meaningful comparisons.

A resource served from memory or disk cache does not represent a full network download. A 304 response is also not equivalent to a 200 response with a body. To measure a fresh download, use the tool's cache-bypass option and verify the actual result, including any service-worker involvement.

5. Caches must select the correct variant

When one URL has response variants based on client decoding support, caches need to select the appropriate one. Vary: Accept-Encoding communicates this dependency to HTTP caches. It does not authorize public storage; cacheability remains a separate concern.

With a CDN or reverse proxy, inspect the route users actually access. An origin response does not prove that the response delivered through a CDN has identical compression. Intermediaries can change resource delivery.

6. Evaluate results, not just a setting

A practical evaluation should record transferred bytes, response time and server resource use. Consider precompressed static assets where supported. For dynamic responses, balance compression cost against transfer savings rather than automatically selecting the highest level.

• Compare the same URL and content version under equivalent cache conditions.
• Repeat measurements instead of judging one request.
• Confirm that the browser still decodes and uses the content correctly.
• Do not expect compression to fix slow queries, long-running JavaScript or poorly sized images.

HTTP compression is one part of performance work. Success means reducing transferred data without introducing costs or errors that worsen the experience, not merely seeing gzip or br in a header.