- Compression reduces ~70% of file size of text-based objects (HTML, CSS, JS, etc), resulting in faster loading and reduced CDN costs
- Some CDNs can compress content on the fly on their edge servers, others can only serve compressed if the origin sent compressed to CDN
- All modern browsers support Gzip compression and will automatically request it
- Brotli compression yields ~20% better results than Gzip, but not many CDNs support it
Introduction to Compression
When a client/browser sends a request to the CDN, it tells the server what types of compressed content it supports by way of the
Accept-Encoding request header. The server will take this into account and send back compressed content if possible. Compression is great for performance and costs: less bytes over the wire results in better load times and less CDN costs. On average, compression reduces file size by 70% and can be as high as 90%.
Most clients (browsers, apps) can handle Gzip compressed content and Gzip is by far the most common compression algorithm used today. Brotli is the new hot kid in town and yields better results than Gzip. Google's Ilya Grigorik published an excellent (technical) article on the Web Fundamentals site: Text compression with GZIP. You can easily find out if your site assets are being compressed with this HTTP Compression Test tool.
CDN → client
What is the behaviour of the CDN when sending objects to the client? Three possibilities:
- Resend from origin only: the CDN only sends compressed to the client if the customer origin server sent the object compressed to the CDN
- Compress on the edge only: the CDN fetches from the customer origin uncompressed and does the compression on the fly on the edge server
- Resend, or compress on edge: CDN fetches from origin compressed; if origin does not serve compressed, the CDN will cache the uncompressed file and do the compression on the fly before serving to clients
CDN ← origin
Can your origin serve content compressed to the CDN? This is important because some CDNs want to fetch compressed from origin and this speeds up cache miss responses. However, some CDNs always fetch uncompressed. See our table below for a CDN behaviour overview.
Is your origin server and CDN sending all these Gzip compressed? The HTML5 Boilerplate Nginx server config shows the following content types that should be served compressed:
Brotli is a compression algorithm created by Google in 2015. They first used it in WOFF2 web fonts.
Brotli does a 10% to 30% better job at reducing file size than Gzip.
The larger the file, the better Brotli performs.
Chrome, Opera, Firefox and Edge browsers support Brotli and so does the Android browser (caniuse.com).
Brotli availability is restricted to HTTPS connections.
Only a few CDNs support Brotli but most do not, so on a non-Brotli CDN even if your origin server can serve Brotli, your users will not get Brotli compressed content.
It's a common misconception that Brotli compression is (much) slower than Gzip, but this is not true: Yes, Brotli can compress faster than gzip
CDNs and Compression
- = Yes
- = Sort of/partially
- = No
- = Extra costs
- = Unknown
|CDN||CDN → client||CDN ← origin||File types||Brotli|
|Limelight||Resend, or compress on edge|
|Verizon Digital Media Services||Resend, or compress on edge|
|StackPath||Resend, or compress on edge|
|CDN77||Compress on edge|
|Fastly||Resend, or compress on edge|
|CDNetworks||Resend, or compress on edge|
|Level 3||Resend from origin|
|G-Core Labs||Resend, or compress on edge|
|Incapsula||Resend, or compress on edge|
|Cloudflare||Resend, or compress on edge|
|CloudFront||Resend, or compress on edge|
|CacheFly||Resend or compress on edge|
|Leaseweb||Resend, or compress on edge|
|ChinaCache||Resend, or compress on edge|
|Akamai||Resend, or compress on edge|
|BelugaCDN||Compress on edge|
|CDNvideo||Resend from origin|
|Tata Communications||Resend from origin|
|QUANTIL||Resend, or compress on edge|
|SwiftServe||Resend, or compress on edge|
More info per CDN
Fastly will fetch compressed from origin. If the origin does not serve compressed responses, Fastly customers can configure their service to do the compression on the edge. See: Enabling automatic gzipping and the relevant API doc. Its nice Fastly allows the customer to specify which content types or file extensions to compress.
Fastly supports Brotli. Read through the Brotli Compression Supportarticle in the Fastly Community portal to learn more.
Cloudflare will fetch compressed from origin and store and serve those compressed responses to the user. If your origin does not serve compressed, Cloudflare will handle that just fine by compressing the response on the edge. Cloudflare can also uncompress a response on the fly if needed. Does Cloudflare gzip resources?.
Enterprise customers can configure which file/content types should be served compressed. By default, Cloudflare serves many file/content types compressed: What Cloudflare gzips.
Verizon Digital Media Services
By default, Gzip compression is disabled, meaning Verizon Digital Media Services (VDMS, aka EdgeCast) will not send content compressed to clients regardless of the behaviour of your origin. Enabling Gzip compression is easy and free for every customer.
If the origin sends compressed to CDN, VDMS will cache the compressed object and serve to eligible clients/browsers. If the origin sends uncompressed to CDN, VDMS will cache the uncompressed object. The VDMS edge server will then compress a cached uncompressed object on the fly before sending to a client/browser if the client/browser indicates it can handle compressed content and if the object is of a content type that should be served compressed. Customers can easily control a list of content types VDMS should serve Gzip compressed.
Tip: make sure your origin sends content compressed to VDMS. If not, cache miss responses will be slow and fat (many bytes over the wire) because VDMS does not gzip on the fly in case of a cache miss !
Files larger than 1 MB will never be served to clients compressed.
Leaseweb publishes which MIME types it compresses on the edge in their KB article
Tata CDN always requests the compressed version of the content regardless of how the client request comes in. Tata CDN does not differentiate based on file size or type unless it is specifically configured to do so (customers can't tweak this self, Tata support is needed). The CDN passes along the
Accept-Encoding header from client to origin. If the origin does not send compressed to CDN, the CDN will not send compressed to clients (unless you use their Intelligent Origin Access service which costs extra).
CDN77 always requests the uncompressed version of the content and will compress an object on the fly if a client requests it compressed. Customers cannot control which content types are served compressed. This is not necessarily bad but in our opinion CDN77 should serve files of more content types compressed. Their current list covers the most popular content types but why not compress e.g.
application/ld+json files too?
CDN77 supports Brotli and that is a good thing.
More CDN Guides