DevBolt
Processed in your browser. Your data never leaves your device.

HTTP Compression for Web Performance

HTTP compression is one of the most impactful web performance optimizations. Enabling Brotli and Gzip on your web server typically reduces transfer sizes by 60-85%, directly improving load times, Core Web Vitals scores, and bandwidth costs. This guide covers setup for all major platforms.

← Back to tools

Brotli / Gzip Compression Tester

Test and compare Brotli, Gzip, and Deflate compression ratios for your text content. See which algorithm gives the best compression for your data.

About Compression Testing

  • Brotli — developed by Google, typically achieves 15-25% better compression than Gzip for text content. Supported by all modern browsers via HTTPS.
  • Gzip — the most widely supported compression format. Based on DEFLATE algorithm. Universally supported by web servers and browsers.
  • Deflate — the underlying algorithm used by both Gzip and Zlib. Lower overhead than Gzip (no header/trailer), but less common as a standalone format.
  • Compression ratios vary by content type — repetitive text like JSON and HTML compresses well (70-90% savings), while already-compressed or random data may not compress at all.
  • Everything runs in your browser — Gzip and Deflate use the native CompressionStream API, Brotli uses brotli-wasm. No data is sent over the network.

Impact on Core Web Vitals

Compression directly affects Largest Contentful Paint (LCP) by reducing the time to download HTML, CSS, and JavaScript. Smaller transfers also improve Time to First Byte (TTFB) since the server sends less data. For a typical 100KB HTML page, Brotli compression reduces the transfer to ~15-25KB, saving 100-300ms on 3G connections and 10-30ms on broadband.

Server Configuration

Nginx: use ngx_brotli module with brotli_comp_level 6 for dynamic content. Apache: enable mod_brotli and mod_deflate. Vercel and Netlify: compression is enabled by default. Cloudflare: enable Brotli in the Speed settings. For static assets, pre-compress files at build time with maximum quality (brotli -q 11) and serve the .br files directly.

Content-Type Best Practices

Compress text-based MIME types: text/html, text/css, text/javascript, application/json, application/xml, image/svg+xml, and application/wasm. Never compress already-compressed formats: JPEG, PNG, WebP, WOFF2, MP4, ZIP. Set a minimum size threshold (typically 256 bytes to 1KB) to avoid overhead on tiny responses. Use Vary: Accept-Encoding header for proper CDN caching.

Frequently Asked Questions

How much does compression improve page load time?

For a typical web page, enabling compression reduces HTML/CSS/JS transfer sizes by 60-85%, which can improve load times by 200ms-2s depending on connection speed. On mobile networks (3G/4G), the improvement is most dramatic. Google's research shows that a 100ms improvement in LCP can increase conversion rates by up to 8%.

Should I use Brotli or Gzip for my web server?

Use both. Configure your server to prefer Brotli (Content-Encoding: br) when the client supports it, and fall back to Gzip. The Accept-Encoding request header tells you what the client supports. All major web servers support this dual configuration. Brotli gives 15-25% better compression but requires HTTPS.

Does Vercel/Netlify/Cloudflare automatically compress responses?

Yes. Vercel, Netlify, and Cloudflare all automatically apply Brotli and Gzip compression to eligible responses. You don't need to configure anything. However, for static assets, you can still benefit from pre-compressing at maximum quality during your build step, as CDN on-the-fly compression typically uses lower quality levels for speed.

Related Inspect Tools