Introduction
Gzip vs Brotli is an important comparison when configuring website compression to reduce the amount of data transferred between a server and a browser. Both methods can compress HTML, CSS, JavaScript, and other text-based assets, but they differ in compression efficiency, processing requirements, and practical configuration. Brotli often produces smaller files for web content, while Gzip remains widely supported and useful across many hosting environments. This guide compares their compression ratios, CPU usage, browser support, and effects on website performance to help you choose the right option.
Website performance is partly a matter of how much data the browser has to download.
CSS, JavaScript, HTML, SVG, JSON, and other text-based resources can contain thousands or millions of characters. Sending those resources in their original form wastes bandwidth because much of the information is repetitive and can be represented more efficiently during transmission.
HTTP compression solves that problem.
For many websites, the two compression methods you’ll encounter most often are Gzip and Brotli.
Both can substantially reduce the amount of data transferred between a server and a browser. Brotli, however, was designed with modern web delivery in mind and can often achieve better compression for web assets.
That does not mean Gzip is obsolete.
Gzip remains widely supported, straightforward to configure, and perfectly capable of delivering compressed websites. Brotli is often the preferred choice when the infrastructure supports it, particularly for static CSS, JavaScript, HTML, and similar text resources.
The right choice depends on more than compression ratio.
You also need to consider compression speed, CPU usage, caching, browser support, server configuration, CDN capabilities, and whether the resource is even suitable for compression.
Quick Answer
For most modern websites, Brotli is generally the better compression choice when it is supported by the server or CDN, particularly for text-based static assets. Gzip remains an excellent fallback and is still widely supported.
In broad terms:
| Factor | Gzip | Brotli |
| Web support | Excellent | Excellent in modern browsers |
| Compression efficiency | Good | Often better |
| Decompression | Fast | Fast |
| Compression CPU cost | Generally lower at comparable settings | Can be higher at stronger settings |
| Static assets | Good | Excellent |
| Dynamic responses | Good | Good |
| Legacy compatibility | Excellent | Very good |
| Modern web preference | Useful fallback | Often preferred |
The important caveat is that Brotli is not automatically faster in every situation.
A smaller compressed file can reduce network transfer time, but aggressive compression can require more server CPU. The best configuration balances transfer savings against the cost of producing the response.
What Is Gzip?
Gzip is a compression format based on the DEFLATE algorithm.
It has been used extensively for web content for many years and is supported by virtually every modern browser and web server.
When a browser requests a resource, it can tell the server which compression formats it supports.
For example:
Accept-Encoding: gzip, br
If the server chooses Gzip, the response may contain:
Content-Encoding: gzip
The browser decompresses the response before using the content.
Gzip is particularly useful for text-based resources such as:
- HTML
- CSS
- JavaScript
- JSON
- XML
- SVG
Its long history is one of its biggest strengths.
There is a large ecosystem of servers, CDNs, libraries, and development tools that support it.
What Is Brotli?
Brotli is a modern compression algorithm originally developed by Google.
It was designed with web compression among its use cases and can often compress text-based resources more efficiently than Gzip.
A Brotli-compressed response typically uses:
Content-Encoding: br
The browser decompresses it automatically.
Brotli is especially useful for:
- HTML
- CSS
- JavaScript
- SVG
- JSON
- Other compressible text resources
One of its advantages is that it can often produce smaller files than Gzip at comparable practical settings.
For websites where bandwidth and transfer time matter, that can be valuable.
Gzip vs Brotli: How They Actually Differ
The biggest difference is the compression algorithm itself.
Gzip uses DEFLATE.
Brotli uses a different compression system designed to achieve strong compression efficiency for modern workloads.
The result is that Brotli can often produce a smaller compressed representation of the same source file.
Imagine:
Original JavaScript
↓
Gzip
↓
150 KB transferred
Original JavaScript
↓
Brotli
↓
125 KB transferred
These numbers are illustrative, not universal.
The actual difference depends on the content and compression settings.
A JavaScript bundle with repetitive patterns may compress differently from a small CSS file or a large JSON response.
This is why real measurements are more useful than assuming a fixed percentage improvement.
Compression Ratio Matters, But So Does Compression Time
It is tempting to ask:
Which algorithm produces the smallest file?
That is only part of the answer.
Servers also need to spend CPU time producing compressed responses.
At higher compression settings, Brotli can require more CPU resources to compress data.
For dynamic responses generated for every request, that tradeoff matters.
For example:
Dynamic HTML
Request
↓
Application generates HTML
↓
Compression
↓
Response
If compression becomes expensive, the server may spend additional CPU time before the visitor receives the response.
For static assets, the situation is different.
A CSS or JavaScript file can often be compressed ahead of time and reused for many visitors.
That makes stronger compression settings more practical.
Brotli Is Particularly Attractive for Static Assets
Static assets are excellent candidates for precompression.
Consider a JavaScript file:
app.js
Instead of compressing it separately for every request, the server or build pipeline can prepare a Brotli representation ahead of time.
Then:
Visitor request
↓
Precompressed asset
↓
Browser
The server does not necessarily need to spend significant CPU compressing the same file repeatedly.
This makes Brotli particularly attractive for:
- CSS
- JavaScript
- HTML that can be pre-generated
- SVG
- JSON
- Static website assets
What Are Brotli Compression Levels?
Brotli supports different quality levels.
Lower settings generally prioritize faster compression.
Higher settings generally prioritize smaller output.
The exact behavior depends on the implementation, but the fundamental tradeoff is:
More compression effort can produce smaller files.
That does not mean the highest setting is automatically best.
Suppose increasing compression quality saves only a few additional kilobytes but dramatically increases build or server processing time.
That may not be a useful trade.
For static assets, higher compression can be reasonable if the asset is compressed once and served many times.
For dynamic responses, moderate settings may make more sense.
Gzip Compression Levels
Gzip also supports different compression levels.
The same general principle applies.
Lower compression levels generally require less CPU and can complete faster.
Higher levels generally attempt to reduce the output size further.
Again, maximum compression is not necessarily maximum performance.
If the server has to spend significantly more CPU time producing a response to save a small amount of transfer size, the result could actually be counterproductive for some workloads.
Which Produces Smaller Files?
In many practical web workloads, Brotli produces smaller compressed files than Gzip.
This is one of its major advantages.
The exact savings vary according to:
- File type
- File size
- Content structure
- Compression level
- Implementation
- Whether the file has already been optimized
For example, minified JavaScript may compress extremely well under both algorithms because it contains repetitive syntax and identifiers.
A small file may show little practical difference.
A large JavaScript bundle may show a more meaningful difference.
Don’t publish a universal statement such as “Brotli makes everything 20% smaller.”
There is no single percentage that applies to every website.
Which Is Faster?
There are two different meanings of “faster.”
Faster to compress
Gzip can be attractive when compression speed and CPU usage are important.
Faster to transfer
Brotli may have an advantage because its output is often smaller.
Therefore:
Gzip may require less work to produce a response, while Brotli may require fewer bytes to transfer.
Which one produces the faster overall experience depends on the workload, network conditions, server resources, and compression configuration.
For precompressed static assets, the server-side compression cost can largely be removed from the request path.
That makes Brotli’s smaller output particularly useful.
Browser Support
Modern browsers widely support Brotli over HTTPS.
Gzip has exceptionally broad compatibility and remains a reliable fallback.
A modern website does not usually need to choose one format and completely abandon the other.
A practical setup can support both.
For example:
Modern browser
↓
Brotli available
↓
Serve Brotli
Older/other client
↓
Gzip available
↓
Serve Gzip
The server or CDN can negotiate the appropriate representation.
This allows you to use Brotli where supported without sacrificing compatibility unnecessarily.
How Content Negotiation Works
Browsers communicate supported encodings through the Accept-Encoding request header.
For example:
Accept-Encoding: gzip, deflate, br
The server examines the available options and selects an appropriate representation.
A Brotli response may include:
Content-Encoding: br
A Gzip response may include:
Content-Encoding: gzip
The browser handles decompression automatically.
You do not normally need JavaScript or application code to decompress the response.
The Vary Header and Caching
Content negotiation introduces an important caching consideration.
If a server returns different representations depending on Accept-Encoding, caches need to understand that the response can vary according to that request header.
This is where:
Vary: Accept-Encoding
can become relevant.
Modern CDNs and web servers often handle this automatically, but it is still useful to understand when diagnosing caching behavior.
A poorly configured cache can potentially serve the wrong representation to a client.
Your CDN or server documentation should be followed when configuring compression and cache behavior.
Compression and CDN Delivery
A CDN can handle compression at the edge.
This can simplify implementation because the CDN may:
- Detect browser support
- Compress responses
- Cache compressed representations
- Serve Brotli to supported browsers
- Fall back to Gzip where appropriate
The exact behavior varies by provider and configuration.
A CDN does not automatically guarantee Brotli delivery.
Always verify the actual response.
How to Check Whether Your Website Uses Brotli
Open Chrome DevTools.
Go to:
Network → select a CSS or JavaScript request → Headers
Look for:
Content-Encoding: br
If you see:
Content-Encoding: gzip
the resource is using Gzip.
You can also inspect:
- Transferred size
- Resource size
- Cache status
- Response headers
- Protocol
- Timing information
For a compressed response, the transferred size may be considerably smaller than the resource’s uncompressed size.
Resource Size vs Transferred Size
This distinction is important when interpreting performance reports.
Suppose:
Resource size: 600 KB
Transferred: 150 KB
The browser ultimately receives only about 150 KB over the network for that response.
The 600 KB figure represents the resource before transfer compression.
Performance tools may display both values differently depending on the tool and context.
Therefore, don’t look at the uncompressed JavaScript size alone when estimating network cost.
But also don’t ignore it.
The browser still has to parse and execute the underlying JavaScript after decompression.
Compression Does Not Reduce JavaScript Execution Cost
This is one of the most important limitations.
Suppose:
JavaScript source: 800 KB
Brotli transfer: 180 KB
The browser still needs to process the JavaScript.
Compression saves network transfer.
It does not turn 800 KB of JavaScript into 180 KB of execution work.
If the website has poor INP because JavaScript creates long tasks, Brotli alone will not solve the problem.
You may need to:
- Remove unnecessary JavaScript
- Split bundles
- Defer non-critical functionality
- Reduce DOM work
- Break up long tasks
- Optimize event handlers
- Remove unnecessary third-party scripts
Compression and execution optimization solve different problems.
Compression Does Not Fix Render-Blocking Resources
A compressed CSS file can still block rendering if it is required before the browser can construct the initial page.
Likewise, a compressed JavaScript file can still delay useful work if it is loaded or executed at the wrong time.
Reducing transfer size helps.
It does not eliminate the resource’s role in the critical rendering path.
This is why compression should be combined with good resource prioritization.
Compression and Core Web Vitals
LCP
Brotli or Gzip can reduce the time required to transfer important text-based resources.
This can help LCP when network transfer is part of the bottleneck.
However, compression cannot fix:
- Slow TTFB
- Oversized LCP images
- Late image discovery
- Render delays
- Poor CSS strategy
INP
Compression may reduce JavaScript transfer size.
It does not directly reduce JavaScript execution cost.
If the problem is main-thread work, optimize the code itself.
CLS
Compression generally has little direct effect on CLS.
Layout instability usually requires a different investigation.
What About Images?
Most common image formats such as JPEG, WebP, AVIF, and PNG already use compression.
Applying Gzip or Brotli to these files generally provides little benefit and can waste server resources.
The same applies to many already-compressed formats.
Compression is primarily useful for text-like content such as:
- HTML
- CSS
- JavaScript
- JSON
- SVG
- XML
Don’t configure your server to blindly compress every file type.
Choose formats that benefit from compression.
What About Fonts?
Font formats such as WOFF and WOFF2 are already designed to store fonts efficiently.
Additional HTTP compression generally provides little or no useful benefit for already-compressed font files.
Focus on:
- Using WOFF2 where appropriate
- Loading only required font files
- Reducing unnecessary weights
- Subsetting when practical
- Managing font priority correctly
This usually produces a better result than attempting to Brotli-compress an already-compressed font.
Gzip vs Brotli for HTML
Both can work well for HTML.
Brotli may provide smaller output, particularly for larger pages with repetitive markup.
For dynamic HTML, however, compression settings should be chosen with server CPU usage in mind.
For static-generated HTML, stronger Brotli compression can be particularly attractive because the output can potentially be prepared ahead of time.
Gzip vs Brotli for CSS
CSS generally compresses well with both methods.
Brotli often provides smaller output.
Because CSS files are frequently static assets, Brotli is usually a strong choice where available.
The bigger performance question remains whether the CSS itself is necessary.
A 300 KB minified stylesheet compressed to 40 KB is still more expensive than a 30 KB stylesheet compressed to 8 KB if the larger stylesheet contains unnecessary code.
Gzip vs Brotli for JavaScript
JavaScript often benefits significantly from compression.
Brotli can frequently reduce the transferred size further than Gzip.
However, JavaScript has two separate performance costs:
Network cost
How many bytes must be transferred?
CPU cost
How much work must the browser perform to parse and execute the code?
Brotli addresses the first.
Reducing unnecessary JavaScript addresses both.
Gzip vs Brotli for JSON and APIs
JSON is highly compressible because it contains repeated keys, structures, and text.
Both Gzip and Brotli can reduce JSON transfer size.
For APIs returning large payloads, compression can therefore make a noticeable difference.
But APIs should also be optimized at the data level.
If a client needs 20 fields and the server sends 200, compression is not the fundamental fix.
Send only the data required where practical.
Should You Use Brotli Everywhere?
No.
Brotli is a strong choice for many web resources, but “use Brotli everywhere” is not a complete optimization strategy.
Consider:
- Resource type
- Browser support
- Server CPU
- CDN capabilities
- Static vs dynamic content
- Compression level
- Cache behavior
- Resource size
For many websites, a practical strategy is:
Brotli for modern clients + Gzip fallback + no compression for resources that are already compressed.
A Practical Configuration Strategy
For a typical website:
Static CSS and JavaScript
Use Brotli where supported.
Consider precompressing assets during the build process.
Dynamic HTML
Use Brotli or Gzip according to server capabilities and CPU requirements.
Avoid unnecessarily aggressive compression if it increases response latency.
JSON/API responses
Compress larger responses when the transfer savings justify the processing cost.
Images
Use appropriate image formats and optimization instead of HTTP text compression.
Fonts
Use efficient font formats and avoid unnecessary font files.
How to Test Compression Properly
Don’t test compression in isolation.
Choose representative pages and measure:
- Uncompressed resource size
- Compressed transfer size
- TTFB
- Resource download duration
- LCP
- INP
- CLS
- Server CPU
- Cache behavior
Then compare Brotli and Gzip under similar conditions.
For static resources, compare the actual generated compressed files.
For dynamic responses, also consider server processing overhead.
The goal is to determine the effect on the complete request, not just the compression ratio.
Common Gzip and Brotli Mistakes
Assuming Brotli is always faster
A smaller file does not guarantee lower total response time if compression itself adds significant server work.
Using maximum compression everywhere
Higher compression levels can increase CPU usage.
Compressing already-compressed files
JPEG, WebP, AVIF, and WOFF2 generally don’t need additional HTTP compression.
Forgetting caching
Compressed responses still need appropriate cache strategies.
Looking only at file size
Network transfer and browser processing are different costs.
Compressing unnecessary code
A smaller unnecessary resource is still unnecessary.
Disabling Gzip completely after enabling Brotli
Gzip remains useful as a fallback.
Installing multiple compression layers
Your web server, CDN, hosting platform, and WordPress plugins may all attempt to manage compression.
Overlapping systems can create confusing configurations.
Assuming a performance plugin is required
Compression can often be handled directly by the web server or CDN.
Not verifying the response
Don’t assume Brotli is active because a setting says “enabled.”
Check the actual Content-Encoding header.
Gzip vs Brotli: Decision Guide
Choose Brotli when:
- Your infrastructure supports it
- Your audience uses modern browsers
- You want smaller text-resource transfers
- Static assets can be precompressed
- CDN support is available
- Server CPU overhead is acceptable
Keep Gzip available when:
- You want broad compatibility
- Some clients do not support Brotli
- Your infrastructure already relies on it
- You need a practical fallback
Focus elsewhere when:
- Images are the main source of page weight
- JavaScript execution is the bottleneck
- TTFB is high
- CSS is excessive
- Third-party scripts dominate
- The page is poorly cached
- The server is overloaded
Compression is useful, but it should be applied according to the bottleneck.
Compression Audit Checklist
Server and CDN
- Brotli is supported where appropriate
- Gzip is available as a fallback
- Compression is applied to suitable text resources
- Already-compressed files are excluded
- Compression levels are reasonable
- Server CPU usage is monitored
- CDN compression behavior is understood
HTTP
- Accept-Encoding is handled correctly
- Content-Encoding is verified
- Cache behavior is checked
- Vary: Accept-Encoding is handled appropriately where needed
Assets
- CSS is minified
- JavaScript is minified
- Unnecessary CSS is removed
- Unnecessary JavaScript is removed
- Images use appropriate formats
- Fonts use efficient formats
Performance
- LCP is monitored
- INP is monitored
- CLS is monitored
- TTFB is investigated where relevant
- Mobile performance is tested
- Field data is reviewed when available
Final Verdict
For most modern websites, Brotli is the stronger default for compressible text resources when the infrastructure supports it.
It can produce smaller transfers than Gzip and is particularly attractive for static CSS, JavaScript, HTML, SVG, and JSON.
But that does not make Gzip irrelevant.
Gzip remains an excellent compatibility option, and the difference between the two can become less important when the actual bottleneck lies somewhere else.
The most effective strategy is usually:
Optimize the asset → minify it → compress it with Brotli where supported → retain Gzip as a fallback → cache it appropriately → measure the result.
And remember that compression only addresses one part of the performance equation.
A perfectly Brotli-compressed JavaScript bundle can still contain too much JavaScript. A compressed HTML document can still be generated slowly. A compressed stylesheet can still contain unnecessary CSS.
The best compression method is the one that reduces transfer cost without creating unnecessary server cost—and the best performance optimization is still removing work that never needed to happen.
Related Guides
This article connects naturally with:
- CSS and JavaScript Minification and Compression – the broader asset-optimization guide
- Browser Caching and Cache-Control Explained – for caching compressed assets
- How a CDN Improves Website Speed – for edge delivery and compression
- HTTP/2 vs HTTP/3 for Website Performance – for modern HTTP transport
- How to Eliminate Render-Blocking Resources – for CSS and JavaScript loading strategy
- How to Improve INP: JavaScript, Event Handlers and Long Tasks – for JavaScript execution problems
- Image Optimization: WebP, AVIF, Sizing and Lazy Loading – for image-specific optimization
- Mobile-First Website Speed Optimization – for performance under mobile constraints
- Website Speed Optimization Checklist – for the complete optimization workflow
ecommended Resources
These resources provide technical details about Gzip, Brotli, and website performance:
- MDN HTTP Compression explains how HTTP compression reduces transferred data.
- Google Brotli provides the Brotli implementation and technical background.
- RFC 7932: Brotli Compressed Data Format documents Brotli’s compression format.
- RFC 1952: GZIP File Format specifies the Gzip file format.
- Google PageSpeed Insights helps evaluate website performance and resource delivery.
- Web Vitals explains Google’s key user-experience performance metrics.