Skip to main content
Imagine you’re packing for a week in Hawaii. If you toss clothes into your suitcase without folding them, you’ll struggle to close it. Fold and compress your clothes and they take up less space — you can fit more. The same principle applies to web traffic: compression reduces file sizes so they use network bandwidth more efficiently. When the server compresses a file, it sends a smaller payload to the browser. The browser decompresses it and displays the original resource. Without compression, the server sends full HTML, JavaScript, CSS, and other assets, which increases page load times—especially for users on slower networks or limited mobile plans.
A slide titled "Data Compression" showing a laptop connected to a desktop monitor with files being packaged into a blue ZIP folder and a progress bar. Icons for different file types (HTML, JPEG, EPS) float above the ZIP to illustrate compression.
Using compression reduces transferred bytes, improves Time to First Byte (TTFB) as seen by end users, and generally produces a faster, more responsive site.
A simple diagram titled "Fast Response" showing a server on the left connected by an arrow to a laptop browser on the right. The arrow is labeled "Sends only useful data," indicating selective data transfer.

​
What to compress

Compress text-based resources. These benefit the most:
A slide titled "Supported Compression" showing six stylized file icons labeled CSS, HTML, XML, JSON, JS and JPEG inside a rounded box. A green checkmark appears beside the box indicating support.
Most image formats and many media files are already compressed at creation time (e.g., Photoshop export, camera encoders). Attempting to compress them again gives little to no benefit and wastes CPU.
A slide titled "Unsupported Compression" showing four file icons (AVI, MP4, MP3, ZIP) inside a rounded box with a red X to indicate they're not supported. The image includes a small "© Copyright KodeKloud" notice at the bottom.

​
Compression methods supported by NGINX

NGINX commonly supports two server-side compression algorithms:
  • gzip — very widely supported and available in most NGINX packages. Uses .gz format. Has compression levels 1–9 (1 = fastest, least compression; 9 = slowest, most compression). Level 6 is a common default.
  • Brotli (br) — often achieves better compression ratios than gzip and supports levels 0–11. Brotli is increasingly supported by browsers but may require additional modules for some NGINX builds.
A slide about Gzip showing a file/zip icon and bullet points noting it was released in the 90s, uses the .gz format, is available on Linux/Unix, and is used via the gzip CLI. To the right is a compression-level scale from 1 to 9 with the default set at 6.

​
Example: compress a file with the gzip CLI

Note: the sizes above are illustrative; the .gz file is the compressed output.

​
Enabling gzip in NGINX

Most packaged NGINX installations already include gzip directives in the http block of /etc/nginx/nginx.conf. They may be commented out — enabling gzip involves a few key settings:
Key parameters:
  • gzip on; — enable gzip compression.
  • gzip_vary on; — add Vary: Accept-Encoding so caches store correct variants.
  • gzip_proxied any; — allow compression for proxied clients (useful when NGINX is reverse-proxying).
  • gzip_comp_level — choose compression level (1–9).
  • gzip_buffers — memory allocated to compression.
  • gzip_http_version — minimum HTTP version required (HTTP/1.1 recommended).
  • gzip_types — list of MIME types to compress. Adjust to match your app (e.g., fonts).

​
Brotli in NGINX

Brotli typically produces smaller payloads than gzip at similar CPU cost, but availability depends on your NGINX build:
  • NGINX Plus: Brotli available via NGINX tooling/modules.
  • Open-source NGINX: Brotli often provided as a third-party module or distro-provided dynamic module; you may need to compile or install the module separately.
A typical Brotli configuration resembles gzip:
If your distribution offers a dynamic Brotli module, enable and load it; otherwise, you can compile NGINX with the Brotli module (see the next section).

​
Compiling NGINX with extra modules (example)

If you compile NGINX to add third-party modules (for example, open-source Brotli), a typical workflow looks like:
Use --add-module (statically compiled) or --add-dynamic-module (loadable module). Compiling is more effort than installing a package, so weigh the benefits (e.g., Brotli) versus maintenance overhead.
Compression improves network performance but consumes CPU. Test different gzip_comp_level / brotli_comp_level values to balance CPU cost and compressed size, especially under high traffic.

​
How to confirm compression is active

Browsers send an Accept-Encoding header to indicate supported encodings (e.g., gzip, br). The server responds with a Content-Encoding header when it compresses a resource. Example request headers from a browser:
Example response headers showing compression:
You can verify compression in multiple ways:
  • Browser DevTools: Network tab → inspect a resource → check Response Headers for Content-Encoding: gzip or Content-Encoding: br.
  • curl:
  • Automated tests or monitoring that check response sizes and headers across your site.
Avoid compressing already-compressed binary formats (images, audio, video, ZIP). Compress text-based assets (HTML, CSS, JS, JSON, XML) and ensure Vary: Accept-Encoding is present so caches handle compressed/uncompressed responses correctly.

​
Next steps

  • Enable gzip or Brotli on a staging/test NGINX server.
  • Measure before/after: compressed vs uncompressed response sizes in DevTools.
  • Tune compression levels for acceptable CPU use and effective size reduction.
  • Consider using a CDN that supports Brotli/gzip and automatic negotiation.
Links and references:

Watch Video