How CDNs Handle GZIP and Brotli for SVG Files

Content Delivery Networks (CDNs) optimize the delivery of Scalable Vector Graphics (SVG) by dynamically applying GZIP or Brotli compression based on browser capabilities and server configurations. Because SVGs are XML-based text files, CDNs treat them similarly to HTML, CSS, or JavaScript assets rather than binary raster images like PNGs or JPEGs. This article explains the technical mechanisms CDNs use to identify, compress, cache, and deliver SVG files using GZIP and Brotli compression algorithms.

MIME Type Identification

CDNs determine whether a file is eligible for text-based compression by evaluating its Content-Type header. For SVG assets, the standard MIME type is image/svg+xml. CDNs maintain a list of compressible MIME types; once image/svg+xml is matched, the edge server flags the file for compression rather than passing it through as a raw binary asset.

Content Negotiation and Algorithm Selection

When a user requests an SVG file, the browser sends an Accept-Encoding HTTP header listing its supported compression formats (for example, Accept-Encoding: gzip, deflate, br).

The CDN edge server handles the request through the following process: 1. Header Evaluation: The CDN checks the client’s Accept-Encoding header for supported algorithms. 2. Prioritization: If the browser supports Brotli (br), the CDN prioritizes it over GZIP (gzip) because Brotli generally yields a 15% to 25% smaller file size for text and XML data. 3. Fallback: If Brotli is not supported, the CDN falls back to GZIP. If neither is supported, the uncompressed SVG is served.

Edge Compression vs. Origin Offloading

CDNs handle the actual compression workload in one of two ways:

• On-the-Fly Edge Compression: The origin server sends an uncompressed SVG to the CDN. The CDN edge node compresses the file into both GZIP and Brotli variants upon the initial request and stores these compressed versions in its edge cache.
• Origin-Compressed Pass-Through: If the origin server has already compressed the SVG, it sends the pre-compressed file along with the Content-Encoding: br or Content-Encoding: gzip header. The CDN caches and delivers these pre-compressed files directly without additional processing.

Caching and the Vary: Accept-Encoding Header

To ensure that clients receive the correct format, CDNs cache separate variants of the same SVG based on compression type.

• The CDN associates the cache key with the encoding type.
• It returns the Vary: Accept-Encoding header to downstream caches and browsers. This header instructs intermediate proxies and browser caches not to serve a Brotli-compressed cached file to a client that only supports GZIP, preventing decoding errors.

Handling Pre-Gzipped SVGs (.svgz)

Some workflows use .svgz files, which are SVGs pre-compressed with GZIP. When serving .svgz files, the CDN must send the header Content-Encoding: gzip alongside Content-Type: image/svg+xml. CDNs typically do not attempt to apply Brotli compression to .svgz files, as the file is already in a compressed binary state, and re-compressing it would cause payload inflation and client-side rendering failures.