RSS Feed Compression: Gzip, Brotli and Reliable Fetching

Short answer: RSS feed compression with gzip or Brotli usually shrinks a feed by 70 to 90 percent, which makes every fetch by readers, aggregators and auto-posters faster and cheaper. Enable it for the feed’s content type on your server (many Nginx setups compress only HTML by default), send Vary: Accept-Encoding, and never serve a pre-compressed file without the matching Content-Encoding header. Test with curl once, and compression becomes one of the easiest wins for feed reliability.

Feeds are fetched far more often than most pages. Every feed reader, aggregator, search tool and automation service polls them on its own schedule, some every few minutes. A 300 KB feed requested a few thousand times a day adds up, and slow responses are one of the reasons tools time out and miss updates. Compression solves most of that with a few lines of configuration. It also has a couple of traps that can make a feed unreadable, which is why it is worth understanding how it works rather than flipping a switch and hoping.

How HTTP compression works for feeds

Compression on the web is negotiated between the client and the server:

1. The client sends an Accept-Encoding header listing the formats it understands, for example gzip, deflate, br.
2. The server picks one, compresses the response body and says which one it used in the Content-Encoding header.
3. The client decompresses the body before parsing it.

If the client does not send Accept-Encoding, a well-behaved server sends the feed uncompressed. That makes compression safe for old clients, as long as the server follows the rules. The full mechanics are described in the MDN reference for Content-Encoding.

XML is an ideal candidate. Feeds repeat the same tag names over and over (<item>, <title>, <link>, <pubDate>), and full-content feeds contain long HTML. Text like that compresses extremely well, typically to a fifth or a tenth of its original size.

Why compression matters for auto-posting

It is tempting to think a feed is too small to matter. Three things change that picture:

• Polling volume. Every tool that watches your feed downloads the whole document on each check, unless it gets a 304 response. More subscribers means more full downloads.
• Timeouts. Tools wait only a limited time for a response. On a slow shared server or a congested connection, a smaller response is more likely to arrive in time. Our article on feed timeouts explains how a slow server breaks auto-posting.
• Full-content feeds. A feed with 50 complete articles can easily reach several hundred kilobytes. Compression turns that into a fraction of the size.

Compression does not replace good caching or a sensible number of items, but it multiplies their effect. If your feed is very large, also look at how many items it should contain.

Gzip vs Brotli for RSS feeds

Enable gzip first. If your server or CDN supports Brotli, enable it as well; negotiation means each client gets the best format it understands. Feed readers and automation services written in server-side languages very often ask only for gzip, so gzip is the format that actually matters for most feed traffic.

Enable compression in Nginx

This is the most common surprise: Nginx’s gzip on; compresses only text/html unless you list other types. A feed served as application/rss+xml is sent uncompressed even though “gzip is on”. Add the feed types explicitly:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    application/rss+xml
    application/atom+xml
    application/xml
    text/xml
    application/feed+json
    application/json
    text/css
    application/javascript;

Every directive is documented in the Nginx gzip module reference. gzip_vary on adds the Vary: Accept-Encoding header, which tells caches to keep compressed and uncompressed versions apart. gzip_proxied any allows compression when Nginx sits behind another proxy or CDN. If the Brotli module is installed, the matching directives are brotli on; e brotli_types with the same list.

Enable compression in Apache, PHP and CDNs

Apache uses mod_deflate. Again, list the feed types:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE application/rss+xml application/atom+xml
  AddOutputFilterByType DEFLATE application/xml text/xml text/html
</IfModule>

With mod_brotli, add the same types with the BROTLI_COMPRESS filter.

PHP applications such as WordPress can compress in PHP with zlib.output_compression, but it is usually better to leave compression to the web server. Compressing in two places at once is a common source of trouble, described below.

CDNs such as Cloudflare compress text responses automatically for clients that ask for it, but check that the feed’s content type is on their compressible list and that the CDN is not caching the feed for too long. Long edge caches are a frequent cause of delayed posts; see RSS feed caching explained.

Traps that make a compressed feed unreadable

Compression problems rarely show up in a browser, because browsers are forgiving. Feed parsers are not. These are the failures we see most often:

• Pre-compressed file without the header. Some caching plugins store feed.xml.gz and a server rule serves it directly. If the response lacks Content-Encoding: gzip, the client receives binary data and reports “not well-formed” or “invalid XML”.
• Double compression. PHP compresses the output, then a proxy compresses it again but labels it once. The client decompresses one layer and finds gzip data where XML should be.
• Compression without negotiation. A misconfigured rule compresses every response, even when the client never sent Accept-Encoding. Simple scripts and older tools then see garbage.
• Missing Vary header. A shared cache stores the Brotli version and serves it to a client that only understands gzip.
• Wrong Content-Length. A length calculated before compression causes truncated or hanging responses with some clients.

Each of these produces errors that look like a broken feed rather than a compression issue, which is why they take long to find. If a feed suddenly fails for one tool but opens fine in the browser, compression is one of the first things to check, together with the Content-Type header e bot protection.

Test your feed’s compression with curl

Three commands tell you everything:

# 1. Does the server compress when asked?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/feed/

# 2. Does it send plain XML when not asked?
curl -s https://example.com/feed/ | head -c 200

# 3. Does the compressed body decode to valid XML?
curl -s --compressed https://example.com/feed/ | head -c 200

In the first response you want to see Content-Encoding: gzip, an RSS or XML Content-Type e Vary: Accept-Encoding. The second and third commands should both start with <?xml oppure <rss. If the second one prints unreadable characters, the server compresses without negotiation. If the third does, the body is compressed twice or mislabelled.

Then run the feed through a validator once more. A broader checklist is in RSS feed validation before auto-posting.

Compression, ETags and 304 responses

Compression and conditional requests work together. A client that already has the latest version sends If-None-Match oppure If-Modified-Since, and the server answers 304 Not Modified with no body at all. That is even cheaper than a compressed response.

One detail: when Nginx compresses a response on the fly, it turns a strong ETag into a weak one (prefixed with W/). That is correct behaviour and conditional requests still work. Problems appear only when an application compares ETags strictly and treats the weak version as different, which can make every request a full download. If your 304 rate is unexpectedly low, compare the ETag the server sends with what clients send back.

What compression does not fix

Compression shrinks the bytes on the wire, but the server still has to build the feed and the client still has to parse all of it. If a feed is slow because of what is inside it, compression only hides part of the problem. Look at these as well:

• Too many items. A feed with hundreds of entries is expensive to generate and parse even when compressed. Twenty to fifty recent items is enough for readers and for auto-posting.
• Huge inline content. Full articles with embedded base64 images, long scripts or tracking markup inflate the feed. Keep media as links or enclosures, not inline data.
• Slow generation. If the server needs several seconds to build the XML, the response is late regardless of its size. Cache the generated feed and rebuild it when a post is published.
• Redirect chains. Every redirect before the feed adds a full round trip. Give tools the final feed address directly.
• Uncompressed images. Feed images are fetched separately by the networks. Large original photos slow down the post, not the feed, so resize them for the web.

Think of compression as the last step of a healthy feed: a sensible number of items, generated quickly, served from a short cache, without redirects, and then compressed. Each step reduces the chance that a tool gives up before it sees your newest item.

A quick checklist

1. Compression is enabled for application/rss+xml, application/atom+xml e application/xml, not only HTML.
2. Vary: Accept-Encoding is present.
3. Only one layer compresses: the web server, the CDN or the application, not two of them.
4. Pre-compressed files are always served with the correct Content-Encoding.
5. A request without Accept-Encoding gets plain XML.
6. The feed still validates and returns 304 for unchanged content.

How PostRSS reads your feed

PostRSS has been reading RSS and Atom feeds and turning new items into social posts since 2014. A fast, compact, valid feed helps any tool that polls it, and PostRSS checks feeds as often as every minute, so a responsive server makes new items appear on your networks sooner. Once the feed is set up, PostRSS publishes each new item, with its image and link, to the networks you connect among 66 supported networks, messengers, team chats and blogs, with options such as keyword filters, UTM parameters and posting windows. See the PostRSS features page for the full list and the pricing page for plan limits. More articles like this one are under the Technical Guide tag.

Related reading

• RSS feed not updating: how to diagnose and fix it
• WebSub explained: RSS push vs polling
• RSS feed pagination: why tools miss some posts

The bottom line

Compressing your RSS feed is one of the cheapest reliability improvements you can make. Gzip is the safe default, Brotli adds savings for clients that ask for it, and both depend on correct negotiation. List the feed content types explicitly, send the Vary header, compress in exactly one place and test with curl. A smaller, faster feed is easier for every reader and auto-poster to fetch on time.

FAQ

Should I compress my RSS feed?

Yes. Feeds are text and compress very well, often to a fifth of their size or less. Compression is negotiated with each client, so tools that do not support it still receive the plain feed.

Why is my feed not compressed even though gzip is on?

Many servers compress only HTML by default. In Nginx, add application/rss+xml, application/atom+xml and application/xml to gzip_types. In Apache, add them to the mod_deflate filter.

Is Brotli better than gzip for feeds?

Brotli usually produces somewhat smaller files, but many server-side feed readers only ask for gzip. Enable gzip for everyone and Brotli as an extra for clients that request it.

Can compression break my feed?

Only when it is misconfigured. Typical causes are serving a pre-compressed file without the Content-Encoding header, compressing twice, or compressing for clients that did not ask for it. A quick curl test reveals all three.

Does compression replace caching?

No. Compression makes each download smaller, while caching and 304 responses avoid downloads altogether. Use both, and keep cache lifetimes short so new items are seen quickly.