What Is Gzip Compression?

The server or delivery layer compresses an eligible response before sending it. The browser receives the smaller representation, expands it locally and uses the original content. Compression changes transfer size, not the logical page source or file meaning. It is especially effective when text contains repeated words, selectors, markup and code patterns.

Gzip is widely supported and often acts as a compatibility baseline. It should not be confused with minification, which removes unnecessary characters from source, or image compression, which uses formats designed for visual media. A site can minify a script, cache it, version its URL and Gzip its network response; each technique solves a different problem.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use Gzip for eligible text responses.
• Do not expect it to optimize already compressed media.
• Measure transferred size rather than source size alone.

Primary specification: MDN HTTP compression reference.

Gzip saves transfer bytes for compressible text while leaving the browser with the same usable resource.

A request commonly includes Accept-Encoding with supported options. The origin, reverse proxy or CDN selects an encoding and returns Content-Encoding: gzip. The response should also vary correctly by encoding so a shared cache does not deliver compressed bytes to a client that cannot decode them.

Compression may happen dynamically for every response or ahead of time for static files. Dynamic compression adapts easily but consumes processing time. Precompressed assets reduce repeated CPU work but require the deployment system to create and publish matching variants. The layer closest to delivery should have one clear ownership model to avoid duplicate work.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. The browser requests a resource.
2. The delivery layer checks encoding support and content type.
3. The response is compressed and labeled.
4. The browser decodes it before use.

The complete exchange is advertise, select, encode, label, transfer and decode.

Brotli was designed with web content in mind and can improve compression density, particularly for static text assets compressed ahead of time. Higher compression settings take more CPU, so the smallest possible output is not automatically the best operational choice. Dynamic HTML often needs a balanced setting that avoids adding server delay.

The browser does not need one universal format. Content negotiation can return Brotli, Gzip or an uncompressed response according to support and policy. Compare actual transfer savings, compression time, cache hit behavior and Time to First Byte rather than selecting a method from a generic percentage claim.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Benchmark representative production resources.
• Avoid maximum compression on every dynamic response.
• Cache each encoding variant correctly.

Use Brotli when measured savings justify it and keep Gzip as a dependable negotiated fallback.

HTML, CSS, JavaScript, JSON, XML, text and SVG usually contain repetition that compresses well. Web fonts may benefit depending on their format, while WOFF2 already includes compression. JPEG, WebP, AVIF, PNG, MP4, ZIP and PDF usually gain little from another Gzip layer and can consume CPU without meaningful savings.

Eligibility should use the response content type and observed results, not only the filename. Dynamically generated routes may lack extensions. Very small responses can grow once headers and compression metadata are included. Define a minimum size, exclude streaming or latency-sensitive cases where appropriate, and verify custom MIME types.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Inventory production MIME types.
2. Group text and already compressed formats.
3. Set a minimum response size.
4. Measure savings and processing cost.

Compress resources that produce material net transfer savings, not every response indiscriminately.

Smaller HTML can arrive sooner after the server begins responding. Smaller CSS and JavaScript reduce download work before rendering and interaction. The effect depends on the page’s bottleneck: compression cannot fix slow application generation, render-blocking architecture, excessive JavaScript execution or oversized images.

Evaluate it alongside First Contentful Paint, Largest Contentful Paint, render-blocking resources and code splitting. The outcome is indirect rather than a ranking promise. Correct, useful pages still need strong search intent alignment and internal discovery.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Test mobile and slower-network conditions.
• Separate download savings from execution time.
• Prioritize high-traffic templates and shared assets.

Gzip is valuable when transferred text is a real page-speed constraint and compression does not add more server delay than it saves.

If a proxy compresses a response that the origin already encoded, the browser may receive unusable bytes or misleading headers. If Content-Length describes the uncompressed body after transformation, clients and monitoring can behave incorrectly. Shared caches that ignore encoding variation may serve Gzip bytes to unsupported clients or keep unnecessary duplicate objects.

High dynamic compression settings can increase response latency and origin load during traffic peaks. Partial responses, streaming endpoints and server-sent events need protocol-aware decisions. Compression can also increase side-channel risk when a response mixes secrets with attacker-controlled input, so sensitive authenticated surfaces deserve a dedicated security review.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Trace origin, proxy and CDN transformations.
2. Inspect headers and decoded bodies.
3. Load-test compression CPU cost.
4. Review authenticated dynamic responses separately.

Compression is safe only when one layer owns encoding and every transformed response carries accurate negotiation, length and cache signals.

A CDN may fetch an uncompressed origin response and compress it at the edge, or it may cache precompressed origin variants. Either design can work. The important requirement is that the cache distinguishes representations and that purge, freshness and validation behavior remain coherent across them.

Cache-hit ratios can fall when configuration creates more variants than necessary. Conversely, stripping Vary without an equivalent provider cache-key rule can mix incompatible responses. Inspect the response delivered publicly and compare it with the origin. Link this audit to CDN delivery, browser caching and cache busting.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Compare edge and origin headers.
• Test Gzip, Brotli and identity requests.
• Confirm purge reaches every stored variant.

A good CDN compression policy produces the correct encoded variant with predictable caching and no origin-edge disagreement.

Choose HTML templates, CSS, JavaScript, JSON, SVG, images and error pages. Record original resource size, transferred size, status, Content-Type, Content-Encoding, Vary, cache status and timing. Repeat at the CDN and through an origin diagnostic route if one exists.

Compare Gzip, Brotli and identity responses and confirm their decoded bodies are equivalent. Test cold and warm cache states, HTTP range behavior where relevant, authenticated responses and peak-load CPU. A high savings percentage on one large script does not prove complete coverage; look for important text responses that remain uncompressed or are compressed twice.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Build a representative resource sample.
2. Request each supported encoding explicitly.
3. Compare headers, bodies and transfer sizes.
4. Test cache states and production load.
5. Prioritize missing high-impact coverage.

A compression audit passes when eligible responses shrink materially, decoded content remains identical and latency or CPU does not regress under realistic load.