HTTP/3 adoption and Brotli vs gzip on Polish sites
39% of 7,785 .pl homepages advertise HTTP/3 and 44% come with Brotli or zstd, mostly via Cloudflare or LiteSpeed; nginx and Apache usually send gzip.
Two in five Polish sites advertise HTTP/3, and fewer than half send their homepage with Brotli or zstd. We read the response headers of the homepages of 7,785 .pl sites in the Tranco list of popular sites (opens in a new tab): 39% name HTTP/3 in their Alt-Svc header, 44% came compressed with Brotli or Zstandard, 50% with gzip and 5.5% not compressed at all.
Who switched them on is clear from the headers. 67% of the sites advertising HTTP/3 sit behind Cloudflare, and most of the rest run LiteSpeed, a web server that offers HTTP/3 out of the box. Sites served by nginx or Apache with no CDN in front mostly send gzip over TCP alone. So HTTP/3 adoption and the choice of Brotli vs gzip are, on the Polish web, mostly the defaults of whoever answers the request. This is the same census behind our study of third-party scripts on Polish homepages, read for transport instead of content.
- 7,785
- 39%
- 44%
- 67%
What HTTP/3 and the content encoding are
HTTP/3 (RFC 9114 (opens in a new tab), June 2022) carries HTTP over QUIC, a transport on UDP, instead of TCP. A lost packet then holds up only the stream it belongs to rather than the whole connection, and a new connection needs fewer round trips before the first byte. A browser doesn't start with it. The first visit goes over TCP, and the server announces HTTP/3 in a response header, Alt-Svc: h3=":443"; ma=86400, which the RFC's section 3.1.1 describes. The browser may then try QUIC, and if UDP is blocked, it falls back to TCP.
Compression is a separate negotiation. The browser lists what it can decode in Accept-Encoding, the server picks one and names it in Content-Encoding. gzip is the old common ground; Brotli (RFC 7932 (opens in a new tab), 2016) compresses text tighter; Zstandard (RFC 8878 (opens in a new tab)) arrived in Chrome 123, whose beta notes list the zstd content encoding (opens in a new tab), and in Firefox 126 (opens in a new tab), both in 2024.
How many Polish sites use HTTP/3?
3,042 sites, 39% of the sample, advertise the final h3 token. Another 4 offer only pre-standard drafts (h3-29, Google's quic), which we don't count. The chart sorts the sites by who answered: Cloudflare when its headers show, another CDN, or, with no CDN in the headers, the web server named in Server.
Cloudflare and LiteSpeed carry HTTP/3 on the Polish web
Share of .pl homepages whose Alt-Svc header advertises h3, by who answered the request · n per group in the table below · 95% intervals
Show the data
| Item | Value | 95% interval | n |
|---|---|---|---|
| Cloudflare | 79% | 77%–81% | 2,563 |
| Apache, no CDN | 5.7% | 4.7%–6.9% | 1,767 |
| nginx, no CDN | 4.2% | 3.3%–5.3% | 1,547 |
| LiteSpeed, no CDN | 96% | 94%–97% | 675 |
| No Server header, no CDN | 11% | 7.9%–14% | 399 |
| Another CDN | 31% | 26%–37% | 284 |
| Other servers, no CDN | 31% | 25%–38% | 192 |
| dcsaas (Shoper), no CDN | 0% | 0%–2.6% | 145 |
| IdeaWebServer, no CDN | 9.8% | 5.9%–16% | 143 |
| Microsoft IIS, no CDN | 1.4% | 0.3%–7.7% | 70 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Two groups stand apart. Behind Cloudflare, 79% of sites advertise HTTP/3; on LiteSpeed with no CDN, 96%. LiteSpeed's documentation (opens in a new tab) (read 14 October 2026) says "QUIC is on by default", and a host has to open UDP port 443 and have a trusted certificate. On nginx and Apache HTTP/3 is rare: 4.2% of nginx sites and 5.7% of Apache sites. nginx ships HTTP/3 in a module (opens in a new tab) that is "not built by default" and still marked experimental. The largest sites advertise HTTP/3 less often. Among the sample's top 1,000, 29% do, against 41% of the sites below them, though both use Cloudflare about equally often. Two things differ. LiteSpeed with no CDN is rarer at the top (2.7% against 9.6%), and the top sites behind Cloudflare advertise HTTP/3 less often (63% against 81%). We can't see why from the headers.
Brotli vs gzip vs zstd: what Polish homepages come with
Our crawler asked for zstd, br, gzip with no preference between them, so each server chose by its own settings. Half the sample answered with gzip. The split follows the same line as HTTP/3.
Behind Cloudflare, homepages come with zstd or Brotli; without a CDN, mostly gzip
Content-Encoding of .pl homepages, by who answered the request · Accept-Encoding: zstd, br, gzip · n per row in the table
- Zstandard
- Brotli
- gzip
- Not compressed
Show the data
| Item | Zstandard | Brotli | gzip | Not compressed | n |
|---|---|---|---|---|---|
| All sites | 18% | 26% | 50% | 5.5% | 7,785 |
| Cloudflare | 55% | 40% | 3.9% | 0.2% | 2,563 |
| Apache, no CDN | 0% | 7% | 83% | 10% | 1,767 |
| nginx, no CDN | 0.3% | 6.3% | 87% | 6.3% | 1,547 |
| LiteSpeed, no CDN | 0% | 82% | 16% | 1.3% | 675 |
| No Server header, no CDN | 1% | 12% | 69% | 18% | 399 |
| Another CDN | 0% | 37% | 56% | 7% | 284 |
| Other servers, no CDN | 1% | 26% | 62% | 11% | 192 |
| dcsaas (Shoper), no CDN | 0% | 0% | 100% | 0% | 145 |
| IdeaWebServer, no CDN | 0% | 0% | 99% | 1.4% | 143 |
| Microsoft IIS, no CDN | 0% | 1.4% | 66% | 33% | 70 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Behind Cloudflare, 55% of homepages came with Zstandard and 40% with Brotli. That matches Cloudflare's compression documentation (opens in a new tab) (last updated 17 April 2026): on the Free plan "content is compressed by default using Zstandard", on Pro and Business with Brotli, on Enterprise with gzip. We can't see a site's plan, but almost every zstd answer in the sample came from Cloudflare.
Without a CDN the defaults are older. nginx's gzip module (opens in a new tab) is off until switched on and has no Brotli in its core; Apache has mod_brotli (opens in a new tab) since 2.4.26, but a host has to enable it. LiteSpeed sites stand out again, with Brotli on 82% of them. Microsoft IIS sites are the least often compressed group.
Is Brotli better than gzip?
To answer it on Polish pages rather than on a benchmark corpus, we compressed the HTML of each homepage again on one machine, with gzip, Brotli and Zstandard at eleven levels, and compared each size with gzip at level 6, zlib's default. 7,435 homepages took part (those cut at the census's 1 MiB cap, and a few with an empty body, did not), with a median of 154 kB of HTML.
Brotli shrinks Polish homepages more than gzip, and more than zstd from mid effort up
Median saving against gzip 6 on the same homepage HTML, by codec and level · Node.js zlib · n = 7,435 homepages · 95% bootstrap intervals
Show the data
| Item | Value | 95% interval | n |
|---|---|---|---|
| gzip 1 | -18% | -18%–-18% | 7,435 |
| gzip 9 | 0.7% | 0.7%–0.7% | 7,435 |
| Brotli 1 | -10% | -10%–-10% | 7,435 |
| Brotli 5 | 10% | 9.9%–10% | 7,435 |
| Brotli 9 | 12% | 12%–12% | 7,435 |
| Brotli 11 | 20% | 20%–20% | 7,435 |
| zstd 1 | -6.9% | -7%–-6.8% | 7,435 |
| zstd 3 | -2.4% | -2.6%–-2.3% | 7,435 |
| zstd 9 | 6.4% | 6.2%–6.5% | 7,435 |
| zstd 19 | 11% | 11%–11% | 7,435 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Against gzip, Brotli wins on size at every level. Against zstd it wins from mid effort up (Brotli 5 beats zstd 9, Brotli 9 beats zstd 19); at the fast end, zstd 1 and 3 make smaller files than Brotli 1 and make them faster. At level 5, Apache's default for dynamic content, the median homepage is 10% smaller than with gzip 6; at level 11, the slowest, 20%. Turning gzip up from 6 to 9 gains almost nothing: 0.7%.
Is Brotli faster than gzip? Does zstd beat it?
Speed is where the codecs part ways. The table has the speed of each level on a seeded sample of 400 homepages, one at a time on one thread (Apple silicon, Node.js zlib; the sizes don't depend on the machine, the speeds do).
| Codec and level | Median saving vs gzip 6 | Saving on all bytes | Median size | Speed, MB/s |
|---|---|---|---|---|
| gzip 1 | -18% | -20% | 30.9 kB | 195.1 |
| gzip 6 | 0% | 0% | 26.1 kB | 81.3 |
| gzip 9 | 0.7% | 1.1% | 25.8 kB | 42.6 |
| Brotli 1 | -10% | -6.3% | 28.4 kB | 452.3 |
| Brotli 5 | 10% | 14% | 23.1 kB | 106.3 |
| Brotli 9 | 12% | 17% | 22.7 kB | 66.7 |
| Brotli 11 | 20% | 24% | 20.7 kB | 1 |
| zstd 1 | -6.9% | -2.3% | 27.5 kB | 596.4 |
| zstd 3 | -2.4% | 3.4% | 26.2 kB | 568.1 |
| zstd 9 | 6.4% | 12% | 23.9 kB | 129.1 |
| zstd 19 | 11% | 17% | 22.8 kB | 4.5 |
Zstandard's case is speed, not size. At its default level 3 it made the median homepage no smaller than gzip 6 did (a "saving" of -2.4%, so slightly larger; across all bytes together 3.4%), but it compressed at 568.1 MB/s; Brotli 5 saves 10% at 106.3 MB/s. Brotli 11 is a level for files compressed once and stored, not for HTML made on every request: it ran at 1 MB/s.
What the servers actually send
The recompression also shows how hard each server compressed. For homepages that came with gzip, we compared the bytes on the wire with what gzip makes of the same HTML at levels 1 and 6.
13% of the gzip homepages were sent at least as large as gzip level 1 makes them, the setting nginx uses unless told otherwise (gzip_comp_level 1). Moving all the gzip homepages to Brotli 5 would save a median 11% of the bytes they send now, about 2.4 kB per homepage view. The zstd homepages, almost all behind Cloudflare, gain about as much: Brotli 5 would take a median 12% off what they send, because zstd as served is about the size of gzip 6. For the homepages sent with no compression, the gain is much larger: the median one weighs 42 kB on the wire, and Brotli 5 would take 78% off it.
Is HTTP/3 faster than HTTP/2?
Our data can't measure that: we know which sites advertise HTTP/3, not which visits used it. What we can show is context from real Chrome users. The Chrome UX Report has a phone TTFB (time to first byte) for 6,076 of the sites, from the 28 days to 22 September 2026, which the third-party scripts study fetched for the same origins.
Behind Cloudflare, sites with HTTP/3 have the lower phone TTFB; without a CDN there is no gap
Median of the origins' TTFB p75 on phones, in seconds, by CDN and whether HTTP/3 is advertised · CrUX, 26 Aug to 22 Sept 2026 · 95% bootstrap intervals
Show the data
| Item | Value | Range | n |
|---|---|---|---|
| Cloudflare, HTTP/3 advertised | 0.72s | 0.68s–0.76s | 1,656 |
| Cloudflare, not advertised | 0.82s | 0.79s–0.9s | 519 |
| No CDN, HTTP/3 advertised | 0.76s | 0.72s–0.82s | 651 |
| No CDN, not advertised | 0.76s | 0.74s–0.78s | 2,977 |
| LiteSpeed with HTTP/3, no CDN | 0.75s | 0.7s–0.82s | 453 |
| nginx or Apache without HTTP/3, no CDN | 0.78s | 0.75s–0.81s | 2,272 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
The two groups disagree. Behind Cloudflare, sites advertising HTTP/3 have a lower median TTFB than those that don't: 717ms against 819ms. Without a CDN there is no gap: 763ms with HTTP/3 advertised, 759ms without. If the protocol alone set TTFB, both groups would show it. Cloudflare sites that don't advertise HTTP/3 may differ in their plan, caching or origin server too, which the headers don't show. We read the chart as context, not as an effect of HTTP/3.
Shop platforms: the platform decides for the shop
For online shops, the platform runs the server, so the shop owner's choice is the platform. We recognised the platforms with the classifier from our study of Core Web Vitals by shop platform. Hosted platforms that run on their own servers show it most plainly.
| Shop platform | Shops | Advertise HTTP/3 | Brotli or zstd | Behind Cloudflare |
|---|---|---|---|---|
| PrestaShop | 557 | 63% | 68% | 44% |
| WooCommerce | 384 | 68% | 67% | 45% |
| Shoper | 227 | 31% | 36% | 34% |
| Custom shop | 224 | 37% | 48% | 37% |
| IdoSell | 217 | 2.3% | 2.3% | 2.3% |
| Magento | 202 | 46% | 69% | 69% |
| Other platforms | 173 | 30% | 45% | 27% |
| Shopify | 127 | 99% | 100% | 100% |
| headless | 44 | 36% | 52% | 48% |
| AtomStore | 36 | 22% | 31% | 31% |
Shopify shops sit behind Cloudflare and get both. Almost all IdoSell shops in the sample (all but a handful) answered from nginx with gzip and no HTTP/3. Shoper shops are split by whether they sit behind Cloudflare, and the open-source platforms (PrestaShop, WooCommerce) by their host.
How to enable HTTP/3 and Brotli
Check what your site sends now
Ask for the page the way a browser does and read the headers:
curl -sI -H 'Accept-Encoding: zstd, br, gzip' https://www.example.pl/ | grep -iE '^(content-encoding|alt-svc|server|cf-ray):'content-encoding: brorzstdmeans modern compression is on; analt-svcline withh3means HTTP/3 is advertised. In Chrome DevTools, the Network panel's Protocol column showsh3on requests that used it.Behind Cloudflare, turn on the switch
HTTP/3 is a toggle in the dashboard (Speed, Settings, Protocol Optimization), available on every plan per Cloudflare's HTTP/3 documentation (opens in a new tab). Compression follows the plan's default; a compression rule can change it.
On LiteSpeed, open UDP port 443
LiteSpeed's documentation says QUIC is on by default; it needs UDP port 443 open and a trusted certificate. Ask your host when
alt-svcis missing.On nginx, build in HTTP/3 and add Brotli
Build nginx 1.25 or later with
--with-http_v3_module, addlisten 443 quic reuseport;next to the TLS listener and sendAlt-Svc: h3=":443"; ma=86400. Brotli needs a module outside the core. If you stay on gzip, raisegzip_comp_levelfrom its default of 1 to 5 or 6 and list your text types ingzip_types.On Apache, enable mod_brotli and put a CDN in front for HTTP/3
AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript application/javascriptturns on Brotli for text. Apache has no HTTP/3, so a CDN or a proxy that speaks it is the way to offer it.Keep gzip, and send Vary
Not every client asks for Brotli or zstd. Keep gzip as the fallback and send
Vary: Accept-Encoding, so caches keep one copy per encoding. 13% of the compressed homepages in our sample didn't send it.
| Who answered | Sites | Advertise HTTP/3 | Brotli or zstd | Compressed at all |
|---|---|---|---|---|
| Cloudflare | 2,563 | 79% | 96% | 100% |
| Apache, no CDN | 1,767 | 5.7% | 7% | 90% |
| nginx, no CDN | 1,547 | 4.2% | 6.5% | 94% |
| LiteSpeed, no CDN | 675 | 96% | 82% | 99% |
| No Server header, no CDN | 399 | 11% | 13% | 82% |
| Another CDN | 284 | 31% | 37% | 93% |
| Other servers, no CDN | 192 | 31% | 27% | 89% |
| dcsaas (Shoper), no CDN | 145 | 0% | 0% | 100% |
| IdeaWebServer, no CDN | 143 | 9.8% | 0% | 99% |
| Microsoft IIS, no CDN | 70 | 1.4% | 1.4% | 67% |
How we measured
What this data can't tell you
One response per site: the homepage, on 24 September 2026, from one machine in Poland. Images, scripts and style sheets may be compressed differently, and a server may answer browsers differently from our crawler, for instance by preferring the first encoding a browser lists. Alt-Svc is an advertisement; a site may also announce HTTP/3 in a DNS HTTPS record, which the census didn't read, so the HTTP/3 share is a lower bound for sites that advertise it only there. The CDN and server come from headers a site can hide or rename, so "no CDN" means none showed. The TTFB comparison is a correlation across hosts, not a test of the protocol.
What percentage of websites use HTTP/3?
On the Polish web, 39% of the 7,785 .pl homepages we read on 24 September 2026 advertised HTTP/3 in their Alt-Svc header. That is the share of sites offering it, not the share of requests made over it: a browser switches only after it has seen the header and when UDP gets through.
Is Brotli better than gzip?
For HTML, yes. On 7,435 Polish homepages, Brotli at level 5 made the median page 10% smaller than gzip at its default level 6, and level 11 20% smaller. Keep gzip as the fallback for clients that don't ask for Brotli.
Does zstd beat Brotli for web content?
Not on size. At its default level 3, zstd made the median homepage about as large as gzip 6 did (-2.4%), while Brotli 5 saved 10% and Brotli 11 20%. Its case is speed: in our benchmark zstd 3 compressed at 568.1 MB/s, Brotli 5 at 106.3 MB/s.
Which browsers support zstd content encoding?
Chrome since version 123 and Firefox since version 126, both released in 2024, accept the zstd content encoding. A server must keep Brotli or gzip for every other client, because it may use zstd only when the request lists it.
How do I check whether a site uses Brotli or HTTP/3?
Request the page with an Accept-Encoding header and read the response headers: curl -sI -H 'Accept-Encoding: br, gzip' https://example.pl/ prints content-encoding: br when Brotli is on, and an alt-svc line with h3 when the server advertises HTTP/3. In Chrome DevTools, the Network panel's Protocol column shows h3 for requests that used it.
Is HTTP/3 faster than HTTP/2?
Our data can't say; it shows who advertises HTTP/3, not what it does to a visit. In the Chrome UX Report, Cloudflare sites advertising HTTP/3 had a lower median phone TTFB than those that didn't (717ms against 819ms), but without a CDN the two were the same (763ms and 759ms), so the gap is more likely the set-up than the protocol.