What gzip and Brotli actually do
A browser cannot display a page until it has received and processed the resources that page needs. Compression reduces the number of bytes transferred for resources such as HTML, CSS, JavaScript, JSON and SVG. The server sends a compressed representation, and the browser decompresses it before using the content. The underlying file does not change; only its representation during delivery does.
Gzip and Brotli are two compression formats used for this job. Gzip is a dependable fallback supported by a wide range of clients and servers. Brotli often produces smaller files for text-based web assets, particularly when files can be compressed ahead of time. A smaller transfer is useful, but it is not the whole performance story: the server must create or retrieve the compressed file, and the browser must still download, decompress and process it.
How the browser and server choose a format
The browser announces the formats it can decode in its Accept-Encoding request header. For example, a request might list br and gzip. If the server has a Brotli version available, it can respond with that version and a Content-Encoding: br header. Otherwise, it may send gzip with Content-Encoding: gzip, or send the uncompressed resource. The Content-Encoding header tells the browser how to decode the response; the file extension alone does not do that job.
Caches need to keep these representations distinct. A response that can differ according to Accept-Encoding should normally include Vary: Accept-Encoding so a cache does not serve a Brotli-encoded response to a client that requested only gzip. If a content delivery network or reverse proxy handles compression, check which layer selects the format and which layer stores the result. Avoid configuring multiple layers to compress an already encoded response.
Which assets benefit most?
Start with text-based assets. HTML, CSS, JavaScript, JSON and SVG often contain repeated words, names and patterns that compression can represent efficiently. Compressing them can reduce transfer size, especially on a connection where bandwidth is limited. Check that the server sends an appropriate Content-Type as well as the intended Content-Encoding; these headers describe different things.
Files already stored in compressed formats usually offer little additional savings. JPEG, PNG, WebP, AVIF, MP4 and WOFF2 are examples where applying gzip or Brotli again may add work without a meaningful reduction. Very small responses may also show little benefit once transfer overhead is considered. Rather than enabling compression indiscriminately, choose eligible content types and verify the results for representative files on your site.
Choosing settings for static and dynamic responses
Static assets, such as versioned CSS and JavaScript bundles, are good candidates for precompression. A build or deployment step can create Brotli and gzip versions once, and the server can select the appropriate file for each request. This makes it practical to use a stronger compression setting without making visitors wait while the server repeats the work. Keep the original asset available for clients that do not accept either format.
Dynamic HTML or API responses may have to be compressed when requested. Higher compression settings can save more bytes, but they generally demand more server processing and may delay the start of a response. A moderate setting can be a better choice when responses are generated frequently or server capacity is constrained. Brotli and gzip do not have to use the same settings, and there is no universal setting that fits every workload.
A simple way to test your configuration
Pick a few representative resources: a large script, a stylesheet, an HTML page and an API response if your site has one. Request each with support for Brotli, then with gzip alone, and inspect Content-Encoding, Vary and transferred size in your browser’s network tools or an HTTP client. Confirm that each version contains the same usable content. Also test without an Accept-Encoding value to make sure an uncompressed response is available when needed.
Compare more than bytes. Look at response time, server processing demands where you can observe them, and whether caching serves repeat requests as expected. A smaller file that takes substantially longer to produce may not improve the experience. For most small teams, a sound starting point is to precompress static text assets with Brotli and gzip, retain gzip as a fallback, and use measured, moderate settings for dynamic responses. Then adjust based on the resources and traffic your site actually handles.
