How to enable brotli compression on a different file type

On my site I serve several large .bin files. (Pieces of gltf formatted 3D models.)

  1. Can Cloudflare brotli-compress them even though they are not on the What will CloudFlare Compress list? I mean I could override the mime type for those files to be one of the matching, but would that work? If so, can I have Cloudflare use the highest compression level?
1 Like

I suspect the only answer is from someone that’s tried or to try it. I’ve not attempted this with brotli, tried something similar with other formats but could never get the format right.

1 Like

I’d ask the question as to whether optimising bin file extension sizes is all that important to begin with. Sure brotli at highest level compression has much smaller compressed file size versus gzip from my comparison benchmarks of various compression algorithms like gzip, xz, lzip, bzip2, brotli and multi threaded pigz, pxz, plzip, pbzip2, lbzip2 and zstd https://community.centminmod.com/threads/round-4-compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-vs-xz-etc.18669/.

But as these .bin files wouldn’t be natively loaded by a page’s HTML page, it isn’t going to affect page load speed as such.

And as you’re serving them from Cloudflare, it isn’t going to impact your bandwidth usage costs besides the initial non-cache hit/missed fetch from your origin. So only benefit is how long it takes a visitor to download the .bin files themselves. If you’re offering up .bin files for download, then using more common bzip2 or xz would be better in pre-compressed downloads i.e. .bin.xz or .bin.bzip2 files.

Not familiar with gltf formatted files but google search says they’re basically json files ?? So I guess highly compressible ? Tried using gzip compression using higher compression based Zopfli compression format ? pigz multi-threaded gzip can use Zopfli compression at level 11 specific compression level and the resulting .gz compressed file is easily decompressed with web browsers via gzip.

1 Like

Also interested in an answer for this one. We’ve udpated (via workers) the mime on our gltf files to application/json to allow gzip / brotli which has brought them down by ~90%. Tend to publish our 3d files with separate assets (i.e. gltf + bin + jpg) but the bin files have draco compression, so not sure how much more is able to be squeezed out of them. I thought I saw someone having success with changing the mime to application/eot but not sure this is a great solution.

@eva2000 bin is a fairly generic extension so understand the confusion, but in this instance they are definitely for use in browser and not as a download. They’re companion files to gltf, used for storing 3D meshes for e.g. webGL … they are also typically quite large, so savings over the wire are desirable. See glTF/README.md at main · KhronosGroup/glTF · GitHub

1 Like

Ok so 5 mins later and I’ve just adjusted the bin mime type from application/octet-stream to application/wasm on all requests with a .bin extension. I’m getting brotli over the wire, and file size on the model I’m testing (which is >draco compressed) is down to ~557kb from ~950kb, so saving > 40%. 3D models are all loading and displaying correctly in macOS Firefox, Chrome, Safari and Edge (Chromium), no issues with the inaccurate mime. I’m not bothered with testing IE, but will try some mobile browsers and larger models when I get a chance.

FYI we were already using Cloudflare workers to proxy requests from a storage bucket against our domain, so it was simply a matter of checking extensions and applying the mime where necessary. It’s straightforward, but can provide a code sample if it helps.

3 Likes

I see, guess using the mime type change is one solution for this then :slight_smile:

This topic was automatically closed after 30 days. New replies are no longer allowed.