Compression (Gzip, Brotli, Zstd)

How HTTP text compression works — Gzip vs Brotli vs Zstd, what Googlebot actually supports, how it feeds Core Web Vitals and crawler fetch limits, and how to enable and verify it by server. The web-performance deep dive on shrinking bytes on the wire.

First published: Jul 3, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #1 in Critical Rendering Path#4 in Web Performance#9 in Technical SEO#15 on the site
AIAuthored byAI v2

Compression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they cross the network, negotiated per request via Accept-Encoding / Content-Encoding, with Vary: Accept-Encoding needed to keep cached variants straight. Brotli usually does better than Gzip on text (often cited around 15–20% smaller, but that's directional, not a guaranteed ratio) and is Google's stated preference when the client supports it; Gzip is the universal fallback; Zstd is a registered but not universally supported third codec, and Google's crawler docs don't state Zstd support for Googlebot. Googlebot explicitly supports gzip, deflate, and Brotli (br) — stated plainly in Google's current crawler docs, informally confirmed by Gary Illyes in 2020, and rooted in Google's 2008 'First date with the Googlebot' post. Compression isn't a ranking factor and doesn't guarantee a TTFB/LCP or Search improvement on its own; it reduces transfer size, which can help TTFB and LCP if that's actually your bottleneck, and it helps pages stay under Google's fetch limit (2 MB for HTML per Illyes' 2026 'Inside Googlebot' post). Don't blanket-exclude formats by extension alone — decide from MIME type and measured output; already-compressed formats (images, video, WOFF2, most PDFs) rarely benefit. Use higher compression for static/pre-compressed assets and a lower/mid-range level for dynamic content, benchmarked against your own traffic and CPU headroom — no single level is universally best. BREACH-style risk is scoped to responses that mix a secret with attacker-reflected content, not a reason to disable compression sitewide. And yes — the Sitemaps protocol explicitly allows gzip-compressed sitemaps.

TL;DR — CompressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. is HTTP content-encoding negotiation: the client sends Accept-Encoding (which can carry q weights and identity), the server replies with Content-Encoding, per request, per resource — and a cacheable response that varies by coding needs Vary: Accept-Encoding. Brotli usually beats Gzip on the same text (often cited around 15–20%, though the exact margin depends on content, codec version, and level) and is Google’s stated preference when supported; Gzip is the universal fallback; Zstd is a registered but not universally supported third codec (Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. docs don’t state Zstd support for GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.). GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. supports gzip, deflate, and Brotli (br) — plainly documented today, informally confirmed by Gary Illyes in 2020, and rooted in Google’s 2008 “First date with the Googlebot” post. Compression isn’t a ranking factor and doesn’t guarantee a TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good./LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. or Search change on its own; it shrinks transfer size, which can help TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. → LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. if that’s your actual bottleneck, and it helps pages stay under Google’s fetch limit (2 MB for HTML per the 2026 “Inside Googlebot” post) — a crawl-efficiency win, not just a speed one. Decide what to (not) compress from MIME type and measured output, not a blanket extension list; BREACH-style risk is scoped to responses mixing a secret with attacker-reflected content, not a reason to disable compression sitewide. Use higher compression for static/pre-compressed assets, a lower/mid-range level for dynamic content — benchmarked against your own traffic and CPU, since no single level is universally best. And the SitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. protocol explicitly allows gzip-compressed sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing..

Evidence for this claim HTTP content coding compresses transferred representations and is negotiated with Accept-Encoding and Content-Encoding. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP compression Evidence for this claim Brotli is an HTTP content coding supported through the br encoding token. Scope: Current official or standards documentation. Confidence: high · Verified: RFC 7932: Brotli

What compression actually is

Compression — properly, HTTP content encoding — shrinks a text-based response body before it crosses the network, so the client downloads fewer bytes and decompresses them locally. It’s negotiated per request. As Google’s LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. docs describe it: “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” A typical header looks like Accept-Encoding: gzip, deflate, br. The server picks one and signals its choice back in the Content-Encoding response header.

Two boundaries worth being precise about, straight from the HTTP specification (RFC 9110): content coding is a transformation of the representation data — the response body — and that’s a different thing from transfer coding, which operates on the message as it moves across a connection. Compression as discussed on this page is content coding, identified by Content-Encoding. The negotiation itself isn’t just a flat list — Accept-Encoding can carry weights (q values) ranking a client’s preference among the codings it’s willing to accept, and it can also express a refusal (q=0); identity is the tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. for “no coding applied.” (RFC 9110, §8.4 and §12.5.3.) And if a cacheable response’s body actually differs by the negotiated coding — a gzip variant and a Brotli variant of the same URL, say — the response needs Vary: Accept-Encoding so a cache doesn’t serve the wrong variant to a client that can’t decode it (RFC 9110, §12.5.5; Apache’s mod_deflate docs describe this exact Vary requirement for compressed cache variants).

It applies to text: HTML, CSS, JavaScript, JSON, SVG, and XML (sitemaps included). Both Gzip and Brotli can shrink text assets substantially — Google’s own PageSpeed guidance cites a ceiling: “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” Treat that as a ceiling, not a typical number — the actual savings on any given response depend on the content’s redundancy, its size, whether it was already minified, the codec/version and dictionary used, and the compression level, so they can’t be generalized from one site’s numbers to another’s.

Two things it is not, and both matter:

  • Not minificationMinification is the process of removing unnecessary characters — whitespace, line breaks, comments, and (for CSS/JS) redundant syntax or long identifiers — from CSS, JavaScript, or HTML source, without changing how the browser parses or executes it. It's distinct from compression (Gzip/Brotli): the two are complementary, applied minify-first, then compress.. MinificationMinification is the process of removing unnecessary characters — whitespace, line breaks, comments, and (for CSS/JS) redundant syntax or long identifiers — from CSS, JavaScript, or HTML source, without changing how the browser parses or executes it. It's distinct from compression (Gzip/Brotli): the two are complementary, applied minify-first, then compress. removes characters from the source (whitespace, comments); compression re-encodes the resulting bytes for transfer. They stack — minify first, then compress — and skipping either leaves savings on the table.
  • Not caching. Compression is about encoding (shrinking bytes on the wire); caching is about storage and reuse (Cache-Control, ETag, CDNs). They’re complementary “how bytes get to the browser efficiently” levers. See cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. for the storage side.

This page is the compression deep dive under the critical rendering pathThe critical rendering path (CRP) is the sequence of steps a browser must complete before it can paint the first pixel: parse HTML into the DOM, parse CSS into the CSSOM, combine them into a render tree, run layout, then paint. Optimizing it shortens time to first render and improves Core Web Vitals. hub, which lists “compress text” as one bullet in its broader critical-bytes checklist. This is where that bullet gets its full treatment.

Gzip vs Brotli vs Zstd

Compression ratio

Brotli generally does better on text, but don’t treat any specific number as universal. Google’s LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. doc is explicit that the audit’s reported savings are computed with Gzip, and “if Brotli is used, even more savings are possible.” Google’s own web.dev Brotli codelab shows one concrete example: a main.bundle.js that was 225 KB uncompressed came down to roughly 61.6 KB with Gzip and about 53.1 KB with Brotli — about 14% smaller with Brotli on that one file. Numbers like that (and the “~15–20%” figure you’ll see elsewhere) are directional, not a guarantee — the real margin on any given asset depends on the codec/library version, the compression level chosen, the content’s redundancy, and whether it was already minified. No codec or quality level is “always best” independent of what you’re compressing; benchmark your own assets rather than porting someone else’s percentage.

Gzip is the universal fallback. It’s supported everywhere, which is exactly why Google recommends it as the safety net: “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.”

Zstd is a third registered codec, not yet a safe default. IANA’s HTTP content coding registry lists gzip, br, and zstd — but registration in that list isn’t the same as universal client, crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., origin, or CDN support, so only advertise what a given request has actually asked for and keep a working fallback path. For HTTP interoperability specifically, RFC 9659 (which updates the earlier RFC 8878 zstd registration) requires decoders to support windows through 8 MB and forbids encoders from requiring a larger window than that — worth knowing if you’re configuring a server or CDN for it. That HTTP content coding, zstd, is also a distinct thing from dictionary-based compression coding dcz; don’t conflate the two when reading vendor docs. Real-world adoption is still early (Caddy, for instance, exposes encode zstd gzip), and Google’s current crawler documentation lists gzip, deflate, and Brotli for its crawlers and fetchers — it does not state Zstandard support for Googlebot, so don’t assume it’s part of that lineup. Treat Zstd as one to watch and enable where your stack supports it and the request asks for it, not as a Gzip/Brotli replacement yet.

Browser and crawler support

Brotli support is now effectively universal in browsers, but that wasn’t always true — and the historical gap is worth knowing because it’s why Gzip fallback still matters. Google’s Lighthouse doc notes: “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” That Safari-on-iOS gap is the canonical example of why you keep Gzip in the chain.

Google recommends Brotli whenever the client can take it: “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.”

When to still fall back to Gzip

Always keep Gzip configured alongside Brotli. Content-encoding is negotiated per request, so a properly configured server serves Brotli to clients that advertise br and Gzip to everyone else automatically — you’re not choosing one or the other, you’re offering both and letting the handshake decide.

Does Google (and Bing) support Brotli and Gzip?

This is the question most compression articles assert without evidence. Here it is with a dated, three-point trail of Google’s own statements.

The 2008 “First date with the Googlebot” post

Google has explained compression in its own voice since 2008. In First date with the Googlebot: Headers and compression (Maile Ohye and Jeremy Lilley), Google wrote that all major search engines and web browsers support gzip compression to save bandwidth, and that you might also see x-gzip (the same as gzip), deflate (which Google also supports), and identity (none). The same post is where Google explains that many file formats — Flash, JPG, PNG, GIF, PDF — are already compressed, so there’s little to gain from compressing them again. It even states a mild preference for gzip over deflate on robustness grounds (gzip carries a checksum and full header, leaving less guesswork). It’s an old post with an “outdated” banner, but the body is live and directly on-topic, and almost no current article cites it.

The 2008 post is quoted here without quotation marks / deep links: the brief verified these lines as exact substrings via direct fetch, but formal #:~:text= fragment links weren’t constructed for that legacy template, so they’re paraphrased rather than presented as verbatim pull-quotes.

Gary Illyes’ 2020 Brotli confirmation

Brotli support for Googlebot was confirmed informally before it was formally documented. In August 2020, Google’s Gary Illyes said, after meeting with the Googlebot team, that he’d been asked a few weeks earlier whether Googlebot supports Brotli compression — and it does. Barry Schwartz reported it the same day at Search Engine Roundtable. That predates the current crawler-overview documentation by about four years — a nice reminder that a rep can confirm crawler behavior long before it lands in the docs.

The current official crawler documentation

Today it’s stated plainly. Google’s Crawler (User Agent) Overview says: “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” And it explains the per-request negotiation the same way a browser does: “The content encodings supported by each Google user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” I say the same thing in my Ahrefs Googlebot guide, which has a dedicated content-encoding section: “Googlebot supports gzip, deflate, and Brotli (br).”

So the lineage is: 2008 blog post → 2020 Illyes confirmation → current crawler docs. This is well-established, not speculative.

The Bing documentation gap

Bing is the honest asterisk here. There’s no detailed, public Bing document stating which content encodings BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. negotiates when crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. ordinary HTML — nothing equivalent to Google’s crawler-overview page. What Bing does document is narrower: its Content Submission API supports Gzip, and you can submit gzip-compressed sitemap files (.xml.gz) to Bing. Because HTTP compression is a standard mechanism that essentially all modern clients negotiate via Accept-Encoding, it’s reasonable to assume Bingbot handles Gzip at minimum — but treat that as an inference from how HTTP works, not as a documented Bing statement. It’s a genuine documentation-transparency gap between the two engines, not a knock on Bingbot’s actual behavior.

Why compression matters for performance and Core Web Vitals

The causal chain (state it precisely)

Compression is not a direct ranking factor. The mechanism it feeds is: smaller transfer size can shorten download time, which can help Time to First Byte and downstream Largest Contentful Paint, which factor into Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — a page-experience signal. Note the “can”: Google’s own guidance bounds the guaranteed outcome to fewer network bytes, not a guaranteed TTFB/LCP win, better Core Web Vitals, or a Search change — if your load is bottlenecked elsewhere (a slow database query, a render-blocking script, DNS/connection setup), compressing an already-small response won’t move the needle. Measure your own bottleneck and field outcome rather than assuming compression alone fixes speed. The thing that’s scored is the speed outcome, not the compression setting. Getting this right matters because a lot of competitor content conflates “helps SEO” with “ranking factor.” (See Time to First ByteTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..)

There’s a nice framing from Google’s Martin Splitt on why raw page weight is a misleading way to think about this: what matters is what actually goes over the wire after compression, not the uncompressed size on disk — a page that looks like 10 MB uncompressed might be five or six over the network. That Splitt point is relayed via Search Engine Journal’s reporting rather than a primary transcript, so it’s paraphrased here, not quoted.

Compression and crawl efficiency — the underrated angle

Compression isn’t only about page speed for humans. It also helps you stay under Google’s fetch limit. As of the 2026 “Inside Googlebot” update (Gary Illyes), Googlebot fetches roughly 2 MB per URL for HTML (down from the older 15 MB figure), and content beyond the limit is truncated, not rejected — only the downloaded portion is passed on for indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Compressing your HTML is one of the levers that keeps critical content inside that budget, so this is a crawl-efficiency concern, not just a Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. one. (More on the limit in crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor..)

The Lighthouse “Enable text compression” audit — exact thresholds

The PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Lighthouse “Enable text compression” audit has precise trigger rules worth naming. Lighthouse gathers text-based responses that don’t already carry a content-encoding of br, gzip, or deflate, compresses each one with Gzip to estimate savings, and — per Google’s doc — “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” So small files below ~1.4 KiB won’t trip the warning even uncompressed. (As of Lighthouse 13 this audit was folded into the broader “Document request latency” insight, but the underlying guidance is unchanged.)

Why a correctly-configured site can still fail the audit

A genuinely useful troubleshooting nugget straight from Google’s PageSpeed documentation: “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” That means a compression checker can report a false negative — “compression isn’t enabled” — even when your server is configured correctly, because an intermediary stripped the Content-Encoding header in transit. Before you assume the report is broken or that your server is misconfigured, test from a clean network path.

TIP Verify the negotiated response instead of trusting the server setting

The public response is what matters. This shows Content-Encoding and the complete header map for each observed redirect hop, but an intermediary can still make one network path differ from another.

Inspect the transfer facts with my free HTTP Header Checker Free

  1. Check representative HTML, CSS, JavaScript, SVG, and XML URLs—not just the homepage.
  2. Confirm the final response reports gzip, br, or another intended Content-Encoding and inspect redirects separately.
  3. Repeat from a clean path or curl with explicit Accept-Encoding when a proxy or security product may be stripping compression.

Static vs dynamic compression — implementation trade-offs

Compression levels

Both algorithms have adjustable levels trading CPU time against ratio:

  • Gzip: levels 1–9.
  • Brotli: levels 0 (no compression) to 11 (maximum), per Google’s web.dev codelab.

Higher levels squeeze harder but cost more CPU time.

The CPU cost — and why static vs dynamic matters

Compression isn’t free; it burns CPU, and the cost profile is completely different for pre-built assets versus content generated on the fly. The right setting isn’t a single universal number for either case — it depends on how often the underlying content changes, how your cache/CDN layer handles the compressed variant, your traffic volume, and what you actually measure, not just a rule of thumb copied from a blog post.

  • Static (pre-compressed / build-time) assets — content that’s stable enough to compress once ahead of time (nginx’s gzip_static and Apache’s mod_deflate both document selecting a precompressed file instead of recompressing per request) can afford higher compression levels, because the CPU cost is paid once at build time rather than on every request. As the web.dev codelab puts it, when compression happens ahead of time, latency from high compression levels isn’t a concern anymore; the trade-off shifts to longer build times, which you pay once, not per visitor.
  • Dynamic (generated-per-request) responses — compressing at the highest levels in real time adds latency to every response, so a lower/mid-range level is a common starting point (tooling sometimes defaults Brotli to around quality 4 for dynamic content as a starting ratio-vs-speed balance) — but treat that as a starting point to benchmark against your own CPU headroom and traffic, not a fixed rule. Google flagged this trade-off as far back as the 2008 post: enabling gzip/deflate has a CPU cost, and on a server already heavily CPU-loaded serving dynamic content, it’s worth weighing before turning maximum compression on for everything.

The practical starting point is higher for static, lower/mid-range for dynamic — but confirm it against your own mutability, cache/CDN behavior, traffic, and a measured before/after, not a level number lifted from an article (including this one).

How to enable compression

The mechanism is the same everywhere — configure the server (or CDN/edge) to compress text responses and advertise Brotli with a Gzip fallback. By platform:

  • Apache — the mod_deflate module (and mod_brotli for Brotli). Google’s PageSpeed guidance points here directly.
  • Nginx — the built-in ngx_http_gzip_module (gzip on; plus gzip_types), and the Brotli module for br.
  • IIS — built-in HTTP Compression (static and dynamic).
  • CDN / edge — Cloudflare, Fastly, and similar typically offer Brotli + Gzip as a toggle; Caddy exposes encode zstd gzip.
  • App frameworks — Node/Express compression middleware; Next.js/Vercel and most modern hosts compress by default.

Then verify it (see the Checklists lens for the exact commands). The fastest check: curl -I -H "Accept-Encoding: br, gzip" https://example.com/ and look for a content-encoding header in the response.

What NOT to compress

Don’t re-compress already-compressed formats: JPG, PNG, GIF, most video, WOFF2 fonts, and most PDFs. They’re already compressed internally; running Gzip or Brotli over them again spends CPU for negligible — occasionally negative — size change. Treat that list as examples, not an exhaustive rulebook — GTmetrix’s own troubleshooting guidance frames it the same way: already-compressed or high-entropy formats “may not benefit and can grow.” The safer general rule is to scope compression by MIME type (text-based formats) and, where you can, check the measured output for a given response rather than trusting a blanket file-extension list, since format and content vary.

There’s also no single universal minimum response size below which compression “doesn’t count” — framing and metadata overhead can erase the savings on small or already-dense bodies, but where that break-even point sits depends on the codec, the implementation, the response headers, and the content itself. Lighthouse’s own 1.4 KiB / 10%-savings thresholds (above) are that specific audit’s suppression rule, not a general size floor — a CDN can (and often does) publish its own, different minimum for when it will bother compressing a response at all.

Compression and BREACH — scoped, not a reason to disable compression sitewide

You may see security advice suggesting you turn compression off out of caution. Don’t generalize from that. BREACH-style risk isn’t a property of “compression” in the abstract — the original research describes a specific attack shape: an HTTP response that (1) is compressed, (2) mixes a secret (like a CSRF token) with (3) attacker-influenced content reflected into the same response, where (4) the attacker can observe the compressed response’s length across repeated requests to infer the secret byte by byte. Apache’s mod_deflate documentation flags exactly this combination as worth a BREACH-specific review. If your responses don’t combine a secret with attacker-controlled reflected input in a compressed body, the classic attack doesn’t apply — the fix is to review and mitigate the specific vulnerable response/context (e.g. don’t reflect user input alongside secrets, add per-request tokens, or rate-limit), not to disable text compression across the whole site.

The sitemap myth — compression is explicitly allowed

One correction worth making loudly: the Sitemaps protocol explicitly allows gzip-compressed sitemaps. Some folks believe you can’t or shouldn’t gzip a sitemap file — that’s wrong. The sitemaps.org protocol permits gzipped sitemap files (.xml.gz) to reduce bandwidth, both engines accept them, and Bing’s own submission tooling supports gzip too. The only caveat is the usual one: the uncompressed sitemap must still respect the protocol’s size limits (50,000 URLs / 50 MB uncompressed). Gzipping the file on the wire is fine and encouraged for large sitemaps.

Where compression sits in web performance

Compression is one lever among the cluster’s siblings. It shrinks the critical bytes the critical rendering pathThe critical rendering path (CRP) is the sequence of steps a browser must complete before it can paint the first pixel: parse HTML into the DOM, parse CSS into the CSSOM, combine them into a render tree, run layout, then paint. Optimizing it shortens time to first render and improves Core Web Vitals. has to download; it lowers TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and downstream LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.; it’s a named PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Lighthouse audit; and it pairs with cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. (encoding vs storage) and render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. (smaller blocking files paint sooner). For the broader toolkit, see web performance tools.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.