Actual encoding
Use the final Content-Encoding response instead of a configuration claim.
Inspect the actual Content-Encoding, transferred size and decoded size.
Enter a website URL to start
Web transfer-size optimization
HTTP compression reduces transfer bytes for HTML, CSS, JavaScript, JSON, XML and SVG. Clients advertise algorithms with Accept-Encoding and servers return the choice in Content-Encoding.
Brotli often compresses text better; Gzip has broad compatibility. Images and video are already compressed and should not usually be recompressed.
Use the final Content-Encoding response instead of a configuration claim.
Show compressed bytes read and bytes after bounded decoding.
Calculate savings from this response rather than a fixed estimate.
A control panel can say compression is enabled while a hostname, route, proxy or MIME configuration still returns an uncompressed page.
Shrink HTML and scripts for faster loading on constrained networks.
Verify what the CDN, reverse proxy and origin actually return.
Compare real transferred and decoded body bytes.
The tool sends Accept-Encoding: br, gzip, deflate and reads the final response once within strict size limits.
Request Brotli, Gzip and Deflate like a modern browser.
Use final Content-Encoding as the source of truth.
Apply compressed and decoded byte caps to prevent oversized payloads.
Show both sizes, savings and missing compression.
It often compresses better, but compression level, dynamic CPU cost and caching affect total performance.
Chunking, read limits, proxy handling and framing can create differences.
JPEG, PNG, WebP, AVIF and video are already compressed and gain little.
No. Results remain on the page and use only short server caching.
Continue with cache policy, HTTP protocols and CDN delivery.