Website Compression Checker

How a Browser and Server Agree on Compression

When requesting a page, a browser can send an Accept-Encoding request header listing compression formats it understands. The server chooses an acceptable representation and, when it compresses the response, declares the choice in Content-Encoding. The browser then decodes the response automatically before rendering the document.

Common values include gzip, br for Brotli, and zstd for Zstandard. These are not file extensions or image optimization settings. They describe how an HTTP response body is represented in transit. A server may also return an uncompressed response, even when the browser advertises supported compression formats.

Read the Headers Before Judging the Result

Interpret a compression check in the context of the resource’s response. The headers below answer different questions, and no single header tells the entire performance story.

Also check the final URL and HTTP status. A redirect, error page, or cached response can be different from the HTML document you intended to examine.

Example of a Brotli-Compressed HTML Response

Suppose a request advertises support for Brotli and gzip. A compatible server might respond with headers like these:

Request:
Accept-Encoding: br, gzip

Response:
HTTP/2 200
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Vary: Accept-Encoding

Here, br means Brotli was selected for this response. It does not establish that JavaScript files, CSS files, or other pages are compressed. A separate request is needed for each resource you want to assess. The response shown is illustrative, not a measured result from this website.

Gzip, Brotli, and Zstandard Are Not the Same

Gzip is a widely supported, dependable choice for compressing text. Brotli can often produce smaller text payloads, depending on the content and settings. Zstandard is another supported HTTP content encoding, but its availability depends on clients, servers, and intermediary infrastructure. There is no universal percentage of savings that applies to every document.

A sensible configuration chooses from encodings supported by the client and server, rather than forcing a single algorithm for every visitor. If a test reports gzip instead of Brotli, that is not automatically a failure: gzip may be the negotiated format for that request.

Calculate Compression Savings Without Guesswork

If you have trustworthy sizes for equivalent uncompressed and compressed response bodies, calculate the reduction as follows:

Compression savings (%) = (uncompressed bytes − compressed bytes) ÷ uncompressed bytes × 100.

For example, an HTML response that measures 120,000 bytes uncompressed and 42,000 bytes compressed has a 65% reduction in body size. That is an illustrative calculation, not a claimed result from the checker. Accurate comparisons require equivalent content; varying pages, responses, or cache states can make a percentage misleading.

Do not confuse transfer size with total page weight. A page includes multiple resources and protocol overhead. Its actual loading performance depends on much more than the compression ratio of one HTML response.

Which Website Files Usually Benefit?

Text-based resources are the strongest candidates for HTTP compression: HTML, CSS, JavaScript, JSON, XML, and text-based SVG. These files often contain repeated text patterns that gzip or Brotli can encode efficiently.

Already compressed assets, including many JPEG, PNG, WebP, AVIF, audio, and video files, often see little benefit from another compression pass. Compressing them again can waste processing time or even increase transferred size. Optimize those formats using techniques appropriate to each format instead.

Why Compression May Appear Disabled

A missing Content-Encoding header is a reason to investigate, not enough evidence to declare the entire server misconfigured. Common explanations include:

• Small response: the server skips compression because the savings would be negligible.
• Already compressed format: the resource is an image, archive, audio file, or another unsuitable type.
• Request negotiation: the testing client did not advertise the expected encoding.
• CDN or proxy rules: an edge server changes or serves the response independently of the origin.
• Redirect or error response: the checker examines a different response from the intended page.
• Cache variation: a cached variant or test timing leads to a different observed header.

Test an ordinary, sufficiently large HTML document and at least one CSS or JavaScript resource before drawing conclusions about site-wide behavior.

Check Compression in Chrome Developer Tools

1. Open the page in Chrome, open Developer Tools, and select Network.
2. Reload the page to capture fresh requests. Select the document request or a relevant stylesheet or script.
3. Open Headers and inspect the response’s Content-Encoding and Content-Type.
4. Compare transferred and resource sizes if the developer tools provide both. Account for cached resources and other display conditions.
5. Repeat for a few important pages and resource types rather than assuming all URLs behave alike.

For deeper diagnostics, pair this inspection with the Page Weight and Resource Analyzer and HAR File Analyzer, after confirming those pages are available on your site.

Where WordPress Site Owners Should Enable Compression

WordPress itself is not usually the primary place where HTTP response compression is controlled. The relevant setting often lives in the web server, hosting panel, reverse proxy, or CDN. Apache, Nginx, managed hosting providers, and CDN services expose different settings and defaults.

First check whether your hosting stack already sends compressed text responses. If not, consult the specific host or server documentation, enable supported compression for appropriate content types, and keep a compatible fallback where necessary. Avoid adding overlapping compression directives across several layers without understanding which server actually serves the response.

After a change, clear relevant caches if required and test again. Compare the same URLs and device conditions, including a public page and a CSS or JavaScript asset. Do not interpret a reduced transfer size as a guaranteed improvement in every Core Web Vitals metric.

Compression, Minification, and Caching Solve Different Problems

Minification removes unnecessary characters from source files. HTTP compression encodes a response more compactly for transfer. Caching can avoid or shorten repeated downloads. These techniques can complement one another, but one does not replace the others.

Also distinguish Content-Encoding from Transfer-Encoding. Content encoding describes the resource representation; transfer encoding describes message framing or encoding between individual HTTP connections. For a gzip or Brotli website audit, the response’s Content-Encoding is the principal signal.

Does HTTP Compression Improve SEO?

Compression is a page-delivery optimization, not a direct promise of higher rankings. Reducing transferable text bytes can contribute to faster loading under suitable conditions. Search performance still depends on content usefulness, indexability, architecture, rendering, and many other factors. Use performance tools to identify material bottlenecks instead of optimizing a compression percentage in isolation.

For broader follow-up checks, review the PageSpeed Insights Checker and Cache Headers Checker once their permalinks are confirmed.

A Practical Compression Audit Checklist

1. Choose a representative public HTML URL and record its final response status.
2. Look for Content-Encoding, the response content type, and relevant cache variation.
3. Check at least one stylesheet and script separately.
4. Investigate missing compression only where the response is a meaningful text-compression candidate.
5. Apply any hosting or CDN changes on a controlled basis and verify the resulting response headers.
6. Measure actual page performance after the change, not merely the presence of a header.

The outcome to aim for is appropriate, reliable compression of useful text responses, not Brotli on every request. A transparent result with clear limits is more actionable than a universal pass-or-fail label.