Compression Check: a beginner's guide
Analyze gzip/brotli/zstd compression support
Compression: the easiest 30% page-weight win on the web
HTTP compression is the practice of having a web server squeeze the response (HTML, CSS, JavaScript, JSON) into a smaller form before sending it across the network, and having the browser decompress it on the other end. The two algorithms in widespread use today are gzip (introduced in HTTP/1.1 in 1999, supported by every browser and server in existence) and brotli (introduced by Google in 2015, now supported by every major browser). Brotli typically produces files about 15–25% smaller than gzip on typical web content, with no extra cost at the browser end. Both are negotiated automatically: the browser sends an `Accept-Encoding` header listing what it supports, and the server picks the best one available.
You should care because compression is the cheapest, easiest, biggest performance win available on any website. Turning on gzip on a server that wasn't using it typically reduces text-asset payloads by 60–80%. Switching from gzip to brotli adds another 15–25% on top. Combined, that means a typical page can ship 70–85% fewer bytes — which translates directly into faster page loads, lower data usage for mobile users, and lower bandwidth bills for the website operator. There is no downside. The only reason any modern website does not use compression is because someone forgot to turn it on.
The five things every compression check looks at:
Is `Content-Encoding: gzip` or `Content-Encoding: br` present in the response headers? If not, no compression is happening.
Are the right content types being compressed? Text assets (HTML, CSS, JS, JSON, SVG) should be. Already-compressed binary formats (JPEG, PNG, MP4, fonts) should not, because the second pass adds CPU cost without saving bytes.
Is brotli being preferred when the browser supports it? Many servers default to gzip even when brotli is available.
Is the compression level reasonable? Levels go from 1 (fast, small savings) to 11 (slow, big savings). For dynamic content, level 4-6 is usually right; for static content served from cache, level 11 is fine.
Are large assets actually being compressed? Some servers have a minimum-size threshold and skip compression for tiny files.
Three questions a compression check answers:
Is my site actually using HTTP compression, or quietly shipping uncompressed text assets?
Am I using brotli, or am I leaving the 15-25% extra savings on the table?
Are there specific content types (like JSON API responses) that are being missed?
The cost of missing compression is shipping 60-80% more bytes than necessary, on every visit, forever. The fix is one configuration change at the web server or CDN level. Modern hosting platforms (Cloudflare, Vercel, Netlify, Fastly) all enable brotli by default for the right content types — but custom servers and self-hosted setups still need to be checked.
The Compression Check endpoint, in plain language
In one sentence: Analyze gzip/brotli/zstd compression support
Tests HTTP (HyperText Transfer Protocol) compression support by individually probing gzip, Brotli, zstd, and deflate encodings. Measures uncompressed and compressed sizes to calculate compression ratios. Detects CDN (Content Delivery Network) providers and checks for proper Vary: Accept-Encoding headers to prevent cache poisoning.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Makes separate requests with individual Accept-Encoding headers (gzip, br, zstd, deflate, identity) to determine exactly which compression algorithms the server supports. Measures the uncompressed baseline size and each encoding's compressed size to calculate compression ratios. Detects the CDN (Content Delivery Network) provider, checks the Vary header for correct caching behavior, and identifies the server's preferred encoding when given a full browser-like Accept-Encoding header.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Compression Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Compression can reduce page size by 60-90% for text-based content. Verifying each encoding individually reveals exactly what the server supports — not just what it prefers. Missing Vary: Accept-Encoding headers can cause CDN (Content Delivery Network) cache poisoning, where users receive incorrect compressed/uncompressed responses.
Picture this in real life. Imagine a performance engineer. Here's the situation they're walking into: Verify compression is enabled and compare encoding efficiency (gzip vs Brotli vs zstd) as part of web performance optimization. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Compression Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Compression Check tool is built for you:
Why does my website feel slow on real devices, even though it looks fine on mine?
Which specific change would give me the biggest speed boost for the least work?
Am I losing visitors and search rankings because of performance problems I cannot see?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Founders watching their conversion rates, marketers trying to lift landing-page revenue, ecommerce operators chasing every percentage point of speed, and developers tuning Core Web Vitals. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and visitors bounce, conversions drop, and your search ranking quietly slides — all from a problem nobody on the team can see. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the free plan. The technical details: `GET /v1/domain/compression`.
When would I actually use this?
If you're still on the fence about whether the Compression Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a performance engineer, a devops engineer, a technical SEO, and an infrastructure engineer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Performance Optimization
Imagine you're a performance engineer. Verify compression is enabled and compare encoding efficiency (gzip vs Brotli vs zstd) as part of web performance optimization.
Why it matters: Identify missing or suboptimal compression with exact byte savings per encoding.
Story 2: CDN Configuration
Imagine you're a devops engineer. Verify CDN (Content Delivery Network) is properly compressing responses and serving correct Vary headers to prevent cache poisoning.
Why it matters: Ensure CDN (Content Delivery Network) compression settings and caching behavior are correctly configured.
Story 3: Competitive Benchmarking
Imagine you're a technical SEO. Compare compression implementation across competitor sites to identify performance gaps.
Why it matters: Benchmark compression ratios and encoding support against competitors.
Story 4: Bandwidth Cost Analysis
Imagine you're an infrastructure engineer. Measure actual compression ratios to estimate bandwidth savings and CDN (Content Delivery Network) cost reduction.
Why it matters: Quantify the bandwidth and cost impact of enabling or upgrading compression.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Compression Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
Before a high-traffic marketing campaign or product launch.
After a redesign, to make sure performance did not regress.
When your conversion rate drops without an obvious cause.
On a recurring schedule, to enforce a performance budget for your team.
If you can see yourself in even one of those bullets, the Compression Check tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Compression Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Compression Check tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/compression?domain=example.com"What you need to provide
There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to check compression for | example.com |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
url | string | The URL (web address) that was tested |
statusCode | number | HTTP (HyperText Transfer Protocol) status code of the response |
contentType | string | Content-Type of the response |
isCompressed | boolean | Whether any compression encoding is supported |
isCompressible | boolean | Whether the content type benefits from compression (text/*, JSON (JavaScript Object Notation), XML, SVG) |
encoding | string | The server's preferred encoding when given a full browser-like Accept-Encoding header |
encodings | object | Per-encoding test results (gzip, brotli, zstd, deflate) — each with supported, compressedSize, compressionRatio, and contentEncoding |
uncompressedSize | number | Uncompressed response size in bytes (baseline measurement) |
compressedSize | number | Best compressed size in bytes |
compressionRatio | number | Best compression ratio (e.g., 0.77 = 77% size reduction) |
bestEncoding | string | The encoding that achieved the best compression ratio |
varyAcceptEncoding | boolean | Whether the Vary header includes Accept-Encoding (critical for CDN (Content Delivery Network) correctness) |
server | string | Server header value |
cdn | object | CDN (Content Delivery Network) detection result (detected, provider, cacheStatus, edgeLocation) |
summary | string | Human-readable summary of the compression analysis |
issues | array | Compression issues detected (missing compression, missing Vary header, etc.) |
recommendations | array | Actionable compression optimization suggestions |
timestamp | string | ISO 8601 timestamp of the analysis |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
CDN (Content Delivery Network) — A worldwide network of servers that store copies of your website close to your visitors so pages load fast.
HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.