Serve precompressed files from CDN (Brotli Level 11/Zopfli)

Brotli Level 11 and Zopfli offer a significant advantage over the lower compression levels used by the CDN for large JSON, CSV and other binary files.

This is mainly useful for static websites (Jamstack) that use such files, e.g. sites hosted on GitHub Pages, GitLab Pages and CloudFlare Pages. Each file would have 3 versions uploaded to the Git repo.

Depending on the Accept-Encoding header in the request, a GET request for domain.com/example.css would serve one of these files from the origin:
example.css - No Content-Encoding header
example.css.br - Content-Encoding: br
example.css.gz - Content-Encoding: gz

CloudFlare already passes through Gzipped content from origin servers but that’s not usable with static sites or Brotli.

For example:

I have a large dataset for my PWA and I’m serving a dataset.json.gz file compressed with Zopfli. This file is then decompressed using the Compression Streams API in JS. The savings of Zopfli over CloudFlare/GitHub Pages Gzip is noticeable. Brotli Level 11 would give the best result but it’s not possible to decompress Brotli in JS easily.

So, you say you have “static” compressed files on your server and want CloudFlare to “catch them” and serve to the visitor? Or your servers is sending “compressed” version, while they do not exist as “phisycall files” on the server?

Moreover, have you tried with some Page rules for your “phisycall files” with the exact needed extension (using wildcard asterix * ) to enable brotli or?

Moreover, how did you tested it that CloudFlare does not already sent the compressed brotli header for that file?

Also, does the CDN location have some caching controls or how does CDN sending the files over the network?

Can you post some HTTP header responses?

For Brotli from origin, you have to have HTTPS, HTTP/2 and Brotli enabled, and not Gzip on origin.
Also “Brotli” enabled in the CloudFlare dashboard.

1 Like

This is mainly for static websites, e.g. GitHub Pages, GitLab Pages and CloudFlare Pages. Each file would have 3 versions.

Depending on the Accept-Encoding header in the request, a GET request for domain.com/example.css would serve one of these files from the origin:
example.css - No Content-Encoding header
example.css.br - Content-Encoding: br
example.css.gz - Content-Encoding: gz

This will reduce the bandwidth and CPU used by CloudFlare’s edge servers by using slightly more cache storage.

As for other types of sites (WordPress or static site hosted with nginx) - Currently CloudFlare only requests Gzip encoded content from origin servers and serves the same file to visitors (without reencoding - so you can serve max level compression files). But you cannot make CloudFlare serve your own Brotli files (at any compression level) at all. Anyway, this is not useful to me since I use GitHub Pages.

This is a simple feature (IMO) that should not require the use of CloudFlare workers.

For Brotli from origin, you have to have HTTPS, HTTP/2 and Brotli enabled, and not Gzip on origin.
Also “Brotli” enabled in the CloudFlare dashboard.

This is a feature request/feedback thread, I’m not asking for help.

Hm, not sure If I understand it good, but as far as I know and saw in FireFox and Chrome, I always got “Content-Encoding: br” for CSS and JS files.
Or at least “x-content-encoding-over-network: br”, while I am sure that the gzip is enabled on the origin (Nginx) also with enabled option using CloudFlare “Enable Brotli”.

Yes, maybe they use “default level compression”. Not sure about it.

The file you got was compressed by CloudFlare from the original uncompressed file. I want to provide my own compressed file with a higher compression level. That is the point of this feature request.

Gzip and Brotli Compression Level Estimator (paulcalvano.com) - the default CloudFlare website could be 10% smaller if they compressed with a higher level.

CloudFlare does not compress with the highest levels due to CPU usage. Therefore I want to do the compression on my own systems for the CDN cache.

1 Like

Cloudflare always use http1.1 + gzip even clients request uncompressed or with accept-encoding: br so basically it a waste of getting brotli enabled on origin