Check GZIP Compression
Test a URL for GZIP status, transfer sizes, savings, and response headers.
GZIP Compression Test for Page Size and Headers
Check gzip compression when you need to know whether a public URL is being delivered with compression and how much transfer size is saved. The tool accepts a domain or URL, then reports whether GZIP is enabled, the compressed size, the uncompressed size, the saving amount, the compression percentage, and a set of HTTP response headers.
This is a targeted delivery check, not a complete performance score. It answers one important question: is the server or delivery layer reducing text-based response size before the page reaches the browser? That answer can help developers, site owners, and SEO reviewers confirm whether a basic performance configuration is active.
How to Test a URL
- Enter the domain or complete page URL in the visible domain field.
- Use the final public address that visitors open, including HTTPS when relevant.
- Select the Check Compression button.
- Review the result table for enabled or disabled GZIP status.
- Compare compressed size, uncompressed size, savings, and HTTP headers.
The page does not ask for files, code, or server access. It checks the public response returned for the submitted address, which makes it useful after hosting changes, CDN updates, performance plugin changes, or server configuration edits.
What the Result Fields Mean
| Result field | What it shows | Why it matters |
|---|---|---|
| GZIP status | Whether compression appears enabled for the tested response. | Confirms the core delivery setting. |
| Compressed size | The transferred size after compression. | Shows the approximate payload sent to the browser. |
| Uncompressed size | The original response size before compression. | Provides context for the savings calculation. |
| Savings and percent | The difference between compressed and original size. | Helps estimate how effective compression is for that URL. |
| HTTP headers | Status, content type, cache instructions, server, and related details. | Gives clues for troubleshooting configuration issues. |
What Compression Does Not Measure
A GZIP result is not the same as a full speed audit. It does not measure image optimization, JavaScript execution, database time, third-party scripts, font loading, layout shifts, or interaction delay. A page can have GZIP enabled and still feel slow if other resources are heavy or the server takes too long to produce the response.
The reverse is also true. If GZIP is disabled, enabling it may reduce transfer size for text-based resources, but it will not fix oversized images or inefficient front-end code. Use this page to confirm compression, then use broader testing when the issue extends beyond response size.
Interpreting Savings by Response Type
Compression savings depend on the type of content being tested. HTML, CSS, JavaScript, JSON, XML, and other text-based resources usually compress well because repeated text patterns can be reduced. Already-compressed formats such as many images, videos, archives, and fonts may show little additional benefit. A low saving percentage is not always wrong if the tested resource is already compressed by design.
- Test the homepage and important templates, not only one random URL.
- Retest after enabling a CDN, proxy, cache plugin, or hosting-level compression.
- Check both server-generated pages and important text-based assets when troubleshooting.
- Record the content type so the compression percentage has context.
Using Headers as Troubleshooting Clues
The header table can explain why the compression result looks the way it does. Content-Type tells you what kind of response was tested. Cache-Control and Expires show caching instructions. Server or CDN-related headers may identify the layer returning the response. Status and protocol details can reveal redirects, errors, or unexpected delivery behavior.
If a tested page has broken internal destinations, use the Broken Link Checker after the compression check. If you also need to confirm HTTPS certificate details, use the SSL Checker. If search visibility is part of the same review, the Google Cache Checker can help compare cached-page evidence after performance changes.
Writing a Useful Compression Report
A clear note should include the tested URL, GZIP status, compressed size, uncompressed size, saving percentage, content type, and date checked. If the result is unexpected, include any relevant server or CDN header. These details give a host, developer, or performance reviewer enough context to reproduce the check and adjust the correct layer.
Creating a Focused Compression Checklist
A useful compression review should cover more than one address. Start with the homepage, then test a representative content page, a tool or application page, and any resource type that is important to the site. This avoids the common mistake of checking only the homepage and assuming the same behavior applies everywhere. Different templates, cache layers, and file types can return different headers.
For each tested address, record the URL, GZIP status, compressed size, uncompressed size, savings percentage, content type, and any server or CDN header that explains where the response came from. If the result changes after a hosting or CDN update, those notes show exactly what improved and which URL still needs attention.
When compression is missing, avoid guessing at the fix from the result alone. The solution may be in the web server, application framework, reverse proxy, hosting control panel, CDN settings, or cache plugin. The checker tells you what the public response looks like; your next step is to adjust the layer that actually controls that response.
Checking Production Rather Than Assumptions
Compression settings are easy to misunderstand because they can be changed at several layers. A developer may enable compression in the application, but a proxy may replace the response. A CDN may compress one resource and ignore another. A hosting panel may apply settings only to certain content types. This is why the public URL matters more than assumptions about the server setup.
When the result is unexpected, test again with the exact final URL and note whether the page redirects. If the first address redirects to another location, the final destination may be the response that needs compression. Clean testing avoids changing the wrong setting and gives the technical team a specific result to reproduce.