Closed DylanPiercey closed 8 years ago
Add the compression
middleware before this middleware (https://github.com/expressjs/compression).
@dougwilson thats a fine solution, and my current one. I was under the impression that it was more performant to serve pre gzipped files and thought it would be a good feature for this lib.
It is never performant to serve static files from Node.js, because all file I/O uses a small thread pool. Many modules currently exist on npm
and there is a PR with some initial ideas about adding it here I have not yet looked at enough besides to say it's missing some error handing that will crash the server.
The module https://github.com/code42day/connect-gzip-static is a good one, and even uses the same core modules this module does.
@dougwilson I think this can rather be meant a little differently. E.g. why not caching gzipped buffers after first read, instead of always streaming the file. This would only take some boilerplate with node core libs. The only non-straightforward thing is to not to allow certain clients (like older IE versions) to retrieve gzip data streams, as they can't accept it properly.
The behaviour could be only enabled with an option flag.
This would mitigate the typical node caveat you mentioned by a lot.
I think it's worth having it in the ecosystem.
Would be nice to have an option to prefer sending gzipped versions of files.