You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this topic has already been raised, but once again I want to describe how important it is for real performance.
Most HTTP responses need to be compressed, now this has to be done on the Node side, this is not effective, and Chrome already supports the new compression method zstd: https://chromestatus.com/feature/6186023867908096
Safari and Firefox also plan to implement it.
It is ideal for fast (faster than gzip) stream compression, but Node does not have normal zstd streaming libraries.
If uWS implements compression on its side and will check the client Accept-Encoding header, if its value contains zstd then compress zstd, if not then gzip.
This is something that will really speed up all existing servers that use uWS, thank you.
The text was updated successfully, but these errors were encountered:
Eventually something like this (at least gzip given that zlib which we already depend on, has gzip support) could be added but in what way is not decided (could be automatic like you propose, or just a helper layer, or completely separate). Automatic is kind of promoting inefficient use, as you could in many case pre-compress the file and store it compressed and uncompressed on disk and then serve it based on headers. Then you would have 0 cost server side. So making it in a way that promotes efficient use is key.
Yes, of course, I had that an explicit method was needed, for example something like this: response.isCompresed(true | false) by default there should be no compression.
This method will make it possible not to use compression in Node.js, this will be very useful, over time zstd can be added later
Hey.
I think this topic has already been raised, but once again I want to describe how important it is for real performance.
Most HTTP responses need to be compressed, now this has to be done on the Node side, this is not effective, and Chrome already supports the new compression method zstd: https://chromestatus.com/feature/6186023867908096
Safari and Firefox also plan to implement it.
It is ideal for fast (faster than gzip) stream compression, but Node does not have normal zstd streaming libraries.
If uWS implements compression on its side and will check the client Accept-Encoding header, if its value contains
zstd
then compress zstd, if not thengzip
.This is something that will really speed up all existing servers that use uWS, thank you.
The text was updated successfully, but these errors were encountered: