Gzip and Brotli Compression: A Complete Guide

Gzip and Brotli compression are methods of shrinking text-based files like HTML, CSS, and JavaScript before they travel from a server to a browser. Smaller files mean faster downloads and quicker page loads. Brotli is the newer, more efficient algorithm, while Gzip is the older universal standard. Together they are one of the simplest, highest-impact speed wins available.

Key takeaways

• Compression reduces the size of text files in transit, so pages load faster without changing how they look or function.
• Brotli typically compresses better than Gzip, often producing files that are noticeably smaller, especially for HTML, CSS, and JavaScript.
• Gzip remains valuable as a universal fallback because it is supported everywhere, while Brotli is the modern default for capable browsers.
• Compression mainly helps text assets. Already-compressed formats like images, video, and many fonts gain little or nothing from it.
• You can verify compression in seconds by checking the content-encoding response header in your browser developer tools.
• On hosted platforms like Framer, compression is applied automatically, so you get the benefit without any server configuration.

What Gzip and Brotli compression are

Compression works by finding repetition and patterns in a file and encoding them more efficiently. Text files are full of repetition: the same HTML tags, the same CSS property names, the same JavaScript keywords appear over and over. A compression algorithm replaces those repeated patterns with shorter references, so the file that travels across the network is much smaller than the original. The browser then decompresses it back to the full version before using it.

Gzip is the long-established standard. It has been supported by every browser and server for years and remains a reliable baseline. Brotli is a newer algorithm developed by Google that uses a more advanced approach and a built-in dictionary of common web text, which lets it squeeze text files smaller than Gzip can. When both are available, modern browsers prefer Brotli and fall back to Gzip when needed.

The key point is that this is a transfer optimization. The files on the server and the files the browser ultimately uses are identical. Compression only changes what happens in between, making the trip across the network faster. That is what makes it such a clean win: real speed improvement with no change to the actual content.

Why compression matters

Every byte you send has to travel across a network, and on slower or mobile connections those bytes add up to real waiting time. Text assets like HTML, CSS, and JavaScript are often the files that block a page from rendering, so shrinking them directly speeds up how quickly a visitor sees and can use your site. Compression frequently cuts the size of these files substantially, which is a meaningful reduction in transfer time.

This connects directly to the metrics that matter for both users and search rankings. Faster delivery of render-blocking resources improves Largest Contentful Paint and overall responsiveness, which feed into your scores on the Core Web Vitals. Google uses these metrics as part of how it evaluates page experience, so compression is not just a nicety. It is part of staying competitive in search.

Compression is also one of the lowest-effort optimizations available. Unlike redesigning a layout or restructuring code, enabling compression is usually a configuration change or, on a managed platform, something already handled for you. That high return for low effort is why it belongs in any serious website speed optimization plan as a foundational step rather than an afterthought.

Brotli versus Gzip

The practical difference between the two comes down to compression ratio and compatibility. Brotli generally produces smaller files than Gzip for the same content, particularly for HTML, CSS, and JavaScript, thanks to its more advanced algorithm and web-tuned dictionary. For a typical site, that means returning a smaller payload to any browser that supports Brotli, which today is the vast majority.

Gzip wins on universality. It is supported by essentially everything, including older clients and tools that may not handle Brotli. This is why the best setup is not choosing one over the other but serving both: Brotli to browsers that accept it, Gzip to everyone else. The server reads the browser’s accept-encoding header and responds with the best format that client supports.

There is also a nuance around compression levels. Both algorithms let you trade processing time for smaller output. Higher Brotli levels produce the smallest files but take more time to compress, which is why static assets are often pre-compressed at a high level ahead of time while dynamic responses use a faster level computed on the fly. Good hosting handles this balance automatically.

What compression does not help

Compression targets text. Files that are already compressed gain little and can even grow slightly if you try to compress them again. This includes most images such as JPEG, PNG, and WebP, video files, and many modern font formats like WOFF2, which is itself already compressed. Applying compression to these wastes effort, so the focus should stay on HTML, CSS, JavaScript, SVG, JSON, and other text-based assets.

How to measure and verify compression

Checking whether compression is active takes only a moment, and it is worth confirming rather than assuming.

• Open your browser developer tools, go to the Network panel, and reload the page. Click a text resource like the HTML document or a stylesheet.
• Look at the response headers for content-encoding. A value of br means Brotli is active, gzip means Gzip is active, and no header means the file is being sent uncompressed.
• Compare the transferred size against the actual resource size in the same panel. A large gap between them confirms compression is working.
• Run Google Lighthouse or PageSpeed Insights. These tools flag text resources that are not compressed and estimate the savings you are leaving on the table.

If you find text assets being served without compression, that is a clear and easy win. On a self-managed server it points to a configuration gap. On a hosted platform it usually means the file type is not being recognized as compressible, which is worth checking but rare.

How to implement compression

On a server you manage directly, compression is enabled in the web server configuration. The general approach is the same regardless of the specific server software: turn on the compression module, specify which content types should be compressed, and choose a compression level that balances file size against processing cost. Static assets are commonly pre-compressed and stored so the server can hand them over without recomputing compression on every request.

The strategy worth following is to serve Brotli where supported and Gzip as the fallback. You enable both, list the text-based content types you want compressed, and let the server negotiate the best option per request based on what the browser accepts. You also want to make sure you are not double-compressing already-compressed assets, which only adds processing work for no benefit.

Compression pairs naturally with other transfer optimizations. Once files are compressed, the next gains come from reducing how much CSS and JavaScript you ship in the first place and from delivering only what the page needs upfront. Techniques like inlining or prioritizing critical CSS work hand in hand with compression: compression makes each file smaller, and shipping less render-blocking code makes the page paint sooner. Used together, they compound.

Common mistakes

• Assuming compression is on without verifying it. Always check the content-encoding header rather than trusting that it was configured.
• Compressing already-compressed files like images and video, which wastes processing time for no size gain.
• Using only Gzip when Brotli is available, leaving meaningful size reductions unclaimed for modern browsers.
• Setting the compression level so high on dynamic responses that the processing time eats into the speed benefit.
• Forgetting to compress less obvious text assets like SVG, JSON, and web manifest files.

Compression in Framer

If your site is built on Framer, compression is one less thing to think about. Framer serves sites through a global content delivery network that applies modern compression automatically. Text-based assets are delivered compressed, with Brotli used where the browser supports it and Gzip as the fallback, all without any configuration on your part. There is no server module to enable and no content-type list to maintain.

This is part of a broader pattern with managed platforms: the foundational performance practices are handled at the infrastructure level so you can focus on design and content. Alongside compression, Framer optimizes and serves images in modern formats, caches assets at the edge close to your visitors, and delivers over HTTP with modern protocols. The combined effect is a site that is fast out of the box rather than one you have to tune by hand.

The takeaway for a Framer site owner is that you should still verify, but you should rarely need to intervene. Open your developer tools, confirm the content-encoding header shows br or gzip on your text assets, and you can trust the platform is doing its job. If you ever see uncompressed text resources, that is worth investigating, but in normal operation compression simply works, leaving you to spend your energy where it moves the needle most.

Frequently Asked Questions

Is Brotli always better than Gzip?

Brotli usually produces smaller files than Gzip for text assets like HTML, CSS, and JavaScript, so for compression ratio it is generally the better choice. However, Gzip has near-universal support, which makes it the safe fallback for any browser or tool that does not accept Brotli. The ideal setup serves Brotli where supported and Gzip everywhere else, rather than picking just one.

Does compression affect image quality or file content?

No. Gzip and Brotli are lossless transfer compression, meaning the browser decompresses the file back to an exact copy of the original before using it. Nothing about the content changes. Compression mainly applies to text files, and it does not reduce image quality. Image optimization is a separate process that uses its own formats and techniques.

How do I know if my site already uses compression?

Open your browser developer tools, go to the Network panel, reload the page, and click a text resource such as the HTML document. Check the response headers for content-encoding: a value of br means Brotli, gzip means Gzip, and no value means the file is uncompressed. Tools like Lighthouse and PageSpeed Insights will also flag any text assets missing compression.

Do I need to configure compression on a hosted platform like Framer?

No. Framer applies modern compression automatically through its content delivery network, serving Brotli where supported and Gzip as a fallback for text assets, with no configuration required. You can verify it by checking the content-encoding header in your developer tools, but in normal operation it simply works, so there is nothing for you to set up or maintain.