CDN Brotli compression
Text should not travel uncompressed from a global edge.
HTML, JS and CSS still dominate many waterfalls. If the edge does not compress them, you pay 210+ locations worth of extra bytes.
Cloud CDN applies Brotli and Gzip for eligible text responses. Clients get the encoding they support. Already-compressed images and binaries are left alone.
Why teams use Aptranet
What CDN Brotli compression looks like on this network.
Cloud CDN caches and accelerates eligible content on 210+ points of presence, with Origin Shield when the origin must stay out of the way.
Smaller HTML, JS and CSS
Brotli typically beats Gzip on text without changing the source files.
Compression at the edge
Origin can send uncompressed or Gzip; the client still sees Brotli when it asks for it.
Every PoP, same policy
You do not enable compression on one region only.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud CDN configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Deliver text through Cloud CDN
HTML, JS, CSS, SVG and JSON are the usual candidates.
- 2Leave media alone
JPEG, WebP, MP4 and zip files should not be recompressed.
- 3Confirm Content-Encoding
Check that browsers receive br or gzip on a test hostname.
- 4Combine with hashed filenames
Compressed hashed assets can use long TTLs.
Outcomes
What changes once the hostname is on Aptranet.
- Text assets are Brotli or Gzip encoded
- Images and binaries are not double-compressed
- Origin compression is optional
- Hashed files stay long-cacheable
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
It can. Cloud CDN still negotiates with the client. Avoid compressing already-compressed formats.
Yes for JSON and other text API bodies that are cacheable or still pass through the edge.
Compression and HTTP/3 stack. See the HTTP/3 CDN page.
Use path-specific behaviour when a client cannot handle encoded responses. Most browsers can.