In my quest for a faster site I´m looking to serve gzipped files.
So I guess I have two options.
1 gzip my files in the build process
2 have the server do the gzipping for me
if I were to go for number 2 I{m I correct in thinking that I would have to add this to my headers configuration in the netlify.toml file?
Does any one have any tips or previous experience with this? Any tips greatly appreciated
3 posts were merged into an existing topic: Improved image optimisation on Netlify / Netlify Large Media
@dev1, this should be happening automatically (the server doing the gzipping for you). Most browsers automatically request the gzipped (or otherwise compressed) version of an asset with the accept-encoding header. For example, Chrome uses the following header when I test:
accept-encoding: gzip, deflate, br
Netlify will send the content gzipped with a response header like this:
content-encoding: gzip
Again, this should already be happening. If not (or if there are any questions), please let us know.
My question relates to this support quest. Is there a way to use content negotiation to serve a pre rendered gzip, deflate or br compressed files?
Thoughts behind this question.
Nope, sorry, not a feature we support today or intend to anytime soon.
I have added your name to the small list of previous requesters so that in case our stance changes, we’ll be sure to let you know.
Hello,
I’ve just connected new website to Netlify. The website consist of only 1 html file for now. When tested in Chrome, the website is not served gziped.
Inspecting Chrome Network tab reveals that the request header does includes accept-encoding: gzip, deflate, br however the response header is missing content-encoding completely.
Any idea how to enable/force gzip-ing?
It will either happen automatically, or not at all - nothing you can configure. For an html file, we should indeed compress automatically. Could you tell me the URL that is misbehaving so I can take a closer look?
Hi, thanks for looking into this.
My website is: https://www.wowidget.com/ and here is Chrome console debug screenshot:
Thanks for that, I can see the same via curl on the command line. It may be that the smallness of the index.html (711 bytes) means we don’t compress it, but I will ask the team in charge of that component of our CDN later this week when I meet with them to investigate for us and will follow up thereafter!
Hey @gondo,
fool was bang on the money. We won’t compress assets smaller than 1kb. I hope this helps!
Hah perfect! Thank you for the investigation. I’ve just increased the page size and as magic, the site is now compressed.
Amazing.
It would be awesome to serve pre-compressed files, especially, if it’s inclusive of Brotli.
Please add me to that request list.
Are you not seeing our automatic brotli encoding work well, @jsphpndr? We don’t have any plans to add that feature in the foreseeable feature, so I’d rather get an understanding of where the system falls short today, rather than only adding your voice to a feature request that is likely to end up WONTFIX status.
I’m looking for less “I want this solution” and more “I am trying to solve this problem and don’t seem to be able to with Netlify”. I assert that “serving pre-built brotli files” is a solution to some problem, so that’s what I’m seeking clarity on 
Problem: If I want to deploy PWA apps based on Wasm and three.js I have to maintain Nginx on a VPS as standard webhosting options don’t allow compression of the less commonly used file types (wasm, dll, glb, gltf). As uncompressed vs compressed takes page sizes from for e.g. 10Mb to 3Mb.
Netlify doesn’t seem to have the option to serve those file types, even if I deal with the compression if I understand this thread correctly
Netlify can certainly serve any file type, but indeed, our compression is applied only to things we are pretty sure will benefit and we don’t have that sureness on files like you mention. What DLL’s does your SPA need, out of curiosity?
I guess that might be behind peoples request, easy for us to test for our use case, not something Netlify will know at a population level. I know glb and gltf files in particular have a wide range of possible content so can vary widely on whether it’s worth compressing them or not.
For example dll’s see inkwasm/dlls at master · Thunderducky/inkwasm · GitHub, not my repo, but a few people in the ink community have been looking at using wasm to put one of the widely used tools online.
Ah, so am I reading this right: these aren’t file your SPA uses, but content you want to share? I say this since we don’t use DLL files during build or at runtime as far as I am aware 
I’ll get some confirmation from our traffic engineering team that my assertion around “what file types we compress” and then we can get the use case ironed into a feature request if things aren’t working in the best way for your site. Not sure how soon I’ll get to talk with them (could be a week), but will follow up here once I have!
Yes if you are referring to a build process on deploy then they aren’t run, they have been generated once and are just part of the static content included with each build of app.
No if you are talking about running in browser as they are used by the app on a worker, in this case it’s a processor written in c# ,that has been packaged to run in browser as wasm/dll’s, that takes a particular from of markdown and returns json.
For scale in this case the dll compress from ~10MB to ~3MB.
For background on glb / gltf files see a similar request at Github pages (Discussions · community · GitHub)
Thanks for taking an interest in this and look forward to hearing back in due course.
I would expect our CDN nodes to serve those files compressed. If that isn’t happening would you please send us a URL for a file at Netlify which should be compressed and it not?
dear reader turns out that if was doing a lot of work 
Works for me for glb, wasm, dll’s so I’m happy!
As an aside yours is the fifth option I’ve tried across webhosting, managed VPS and other Netlify style providers and the only one that actually works, I’d definitely add that to your ads / support info.
