Brotli vs Gzip Compression: Reduce HTML, CSS & JavaScript Size

Brotli and Gzip reduce the number of bytes transferred for compressible HTTP responses such as HTML, CSS, JavaScript, JSON, XML and SVG.

The goal is not to compress every file type at the highest possible level. The goal is to compress resources that benefit from text-oriented lossless compression, choose a sensible algorithm and compression level, avoid wasting CPU on already compressed formats, and verify that clients and caches receive the correct encoded representation.

This guide explains how Accept-Encoding, Content-Encoding and Vary: Accept-Encoding work, how Brotli compares with Gzip, when dynamic or precompressed delivery makes sense, and how to test compression on Nginx, Apache, WordPress, CDN-based sites and Blogger-managed pages.

Last verified: September 16, 2026.

---

---

1. What Is HTTP Content Compression?

HTTP content compression reduces the size of a representation before it is transferred over the network. The browser advertises the encodings it understands, the server chooses an encoding it supports, and the response identifies the selected encoding.

This is lossless representation compression: after decoding, the browser receives the original content represented by the resource.

---

2. How Accept-Encoding Works

The browser sends an Accept-Encoding request header listing encodings it can decode.

Accept-Encoding: br, gzip

Modern browsers may also advertise additional encodings such as Zstandard, but Brotli and Gzip remain widely relevant for web delivery.

---

3. How Content-Encoding Works

The response tells the client which representation encoding was actually used.

Content-Encoding: br

or:

Content-Encoding: gzip

---

4. Why Vary: Accept-Encoding Matters

When caches may store different encoded variants of the same URL, they need to know that the response changes according to the client's supported encoding.

Vary: Accept-Encoding

This helps a shared cache keep compatible encoded representations separate.

---

5. Content-Encoding Is Not Transfer-Encoding

---

6. Which Resources Usually Benefit?

• HTML
• CSS
• JavaScript
• JSON
• XML
• SVG
• Plain text
• Many text-based API responses

These formats usually contain enough repeated text patterns to compress effectively.

---

7. Which Resources Usually Should Not Be Recompressed?

• JPEG
• WebP
• AVIF
• MP4 and other compressed video
• MP3/AAC and other compressed audio
• ZIP/GZIP archives

HTTP recompression of already compressed files often saves little and adds CPU work.

For image-specific optimization, use the WebP & AVIF Image Optimization Guide.

---

8. Brotli vs Gzip

---

9. Do Not Promise a Fixed Compression Percentage

Compression results vary with file type, file size, minification, repeated strings and compression level. Use actual transfer measurements from your site instead of quoting a universal percentage.

---

10. Compression Level Is a CPU vs Size Trade-off

Higher settings usually spend more CPU looking for a smaller representation. Strong settings are easier to justify for files compressed once during deployment than for dynamic HTML or API responses compressed on every request.

---

11. Dynamic Compression

Dynamic compression happens while the response is generated or served. It is useful for HTML and changing JSON/API output, but it consumes CPU during live requests.

---

12. Precompressed Static Assets

app.js
app.js.gz
app.js.br

styles.css
styles.css.gz
styles.css.br

Precompression moves expensive work out of the request path and is well suited to versioned static files.

---

13. Nginx Gzip Example

gzip on;
gzip_vary on;

gzip_types
    text/plain
    text/css
    application/javascript
    application/json
    application/xml
    image/svg+xml;

Nginx documents gzip_types for adding MIME types beyond the default HTML behavior, and gzip_vary can add Vary: Accept-Encoding.

---

14. Nginx Precompressed Gzip

The optional ngx_http_gzip_static_module can serve existing .gz files.

gzip_static on;

This module is not built by default in every Nginx installation.

---

15. Brotli on Nginx Requires Module or Platform Support

Do not assume Brotli directives are universally available in Nginx. Availability depends on the build, added modules, managed host or CDN layer.

---

16. Apache Compression

Apache commonly uses mod_deflate for Gzip-compatible compression and mod_brotli where Brotli support is available.

On shared hosting, verify loaded modules and host defaults before adding rules to .htaccess.

---

17. LiteSpeed and OpenLiteSpeed

LiteSpeed-family servers can provide compression through their own server configuration and hosting panels. Follow the actual platform controls rather than assuming Nginx or Apache directives apply.

---

18. CDN and Cloud Compression

A CDN can compress eligible responses at the edge or serve compressed variants from cache. Verify Brotli/Gzip support, MIME rules, fallback behavior and cache handling in the current provider documentation.

---

19. Compression and Browser Caching Work Together

Compression reduces bytes when a response is transferred. Browser caching can avoid that transfer entirely on repeat requests. They are complementary optimizations rather than substitutes.

---

20. Compression Does Not Fix TTFB by Itself

Compression does not solve slow database queries, application work or server queueing. Aggressive dynamic compression can also add CPU cost.

For backend diagnosis, use the TTFB Optimization Guide.

---

21. Compression and HTTP/3 Solve Different Layers

HTTP/3 changes transport behavior. Brotli and Gzip change representation size. A site can use both together.

See the HTTP/3 & QUIC Performance Guide.

---

22. Compression and Minification Are Different

Minification removes unnecessary source characters. HTTP compression encodes the resulting file more efficiently for transfer. Production CSS/JS can use both.

---

23. SVG Is a Good Compression Candidate

SVG is XML-based text, so it can often benefit from HTTP compression even though it represents graphics.

---

24. JSON and API Responses

JSON often compresses well because property names and syntax repeat. For latency-sensitive APIs, measure reduced transfer size against dynamic compression CPU cost.

---

25. Small Responses May Not Need Compression

Very small payloads can gain little from compression. Many servers therefore provide minimum-size controls. Choose thresholds based on your actual stack rather than one universal value.

---

26. Security Considerations

Compression over encrypted connections has known side-channel considerations in some architectures where secrets and attacker-controlled input appear in the same compressed response. Treat this as a security-design issue and follow current server/security guidance for sensitive endpoints.

---

27. WordPress Compression Optimization

Compression may already be handled by the host, Nginx/Apache/LiteSpeed, a CDN or reverse proxy. Inspect actual response headers before adding another optimization layer.

---

28. Blogger Compression Limitations

Blogger users generally cannot configure Google's underlying origin compression directly.

• Inspect Content-Encoding in DevTools.
• Confirm what Blogger/Google already serves.
• Optimize externally hosted resources you control.
• Do not apply Nginx/Apache directives to Blogger-hosted HTML.

---

29. Verify Compression in Chrome DevTools

Open DevTools → Network, reload the page and select a text resource. Inspect the response headers for:

Content-Encoding: br

or:

Content-Encoding: gzip

Also compare transferred size with decoded resource size where DevTools exposes both.

---

30. Test With curl

curl -I \
  -H "Accept-Encoding: br, gzip" \
  https://example.com/

Inspect Content-Encoding and Vary. Behavior can differ depending on your curl build and whether the body is requested/decoded.

---

31. Compression Decision Matrix

---

32. Safe Compression Optimization Workflow

1. Inventory large text responses.
2. Inspect current Content-Encoding.
3. Confirm origin/CDN support.
4. Enable one compression layer intentionally.
5. Choose appropriate MIME types.
6. Avoid already-compressed formats.
7. Measure transferred bytes.
8. Measure CPU/latency for dynamic compression.
9. Verify Vary: Accept-Encoding.
10. Retest under realistic conditions.

---

33. Before-and-After Verification Checklist

• Record URL and date.
• Record original transfer size.
• Check request Accept-Encoding.
• Check response Content-Encoding.
• Check Vary: Accept-Encoding.
• Test HTML, CSS, JavaScript, JSON and SVG.
• Confirm image/video/archive formats are not pointlessly recompressed.
• Check CPU usage for dynamic compression.
• Check TTFB under realistic load.
• Test CDN and origin behavior separately.

---

34. Common Brotli and Gzip Mistakes

• Compressing everything: already compressed media often gains little.
• Using maximum dynamic compression blindly: CPU cost can outweigh marginal savings.
• Forgetting Vary: shared caches can mishandle encoded variants.
• Confusing Content-Encoding and Transfer-Encoding: they solve different protocol concerns.
• Assuming Brotli exists in every Nginx build: module availability varies.
• Stacking duplicate host/CDN/plugin compression: inspect actual response headers first.
• Using server directives on Blogger: Blogger does not expose Nginx/Apache configuration.

---

Frequently Asked Questions

Is Brotli better than Gzip?

Brotli can produce smaller text representations at suitable settings, while Gzip remains extremely mature and broadly compatible. The better choice depends on your delivery stack, resource type and CPU budget.

Should I enable both Brotli and Gzip?

Many deployments use Brotli for compatible clients and retain Gzip as a fallback. The server or CDN negotiates an encoding based on client support.

Should images be compressed with Brotli or Gzip?

Usually not when they are already in compressed formats such as JPEG, WebP or AVIF. Optimize those with image-specific tools instead.

Does compression improve Core Web Vitals?

Smaller text responses can reduce transfer time when bandwidth is a bottleneck, but compression alone does not guarantee good LCP, INP or CLS.

Does compression reduce TTFB?

Not necessarily. Dynamic compression consumes CPU and can add work to the response path. Its primary purpose is reducing response-body transfer size.

What does Vary: Accept-Encoding do?

It tells caches that a response can differ according to the client's supported content encodings.

Should CSS and JavaScript still be minified?

Yes. Minification and HTTP compression solve different problems and can be used together.

Can Blogger users enable Brotli manually?

Not on Google's underlying Blogger infrastructure. Blogger users can inspect what Google serves and optimize only resources hosted on infrastructure they control.

---

Final Takeaway

Brotli and Gzip are most useful when they reduce transfer size for text-like responses without adding unreasonable server work.

Compress HTML, CSS, JavaScript, JSON, XML and SVG; avoid wasting CPU recompressing already compressed images, audio, video and archives; and use precompression for static assets where your delivery stack supports it.

The strongest configuration is the one that delivers smaller compatible representations, correct cache variants and sensible CPU cost across the origin, CDN and browser.

•