3 ms·

As they describe being open to ideas and feedback: maybe using static compression could help. The concept is to pre-compress files (have foo.html.gz available n

by tleb_ 5y ago

As they describe being open to ideas and feedback: maybe using static compression could help. The concept is to pre-compress files (have foo.html.gz available next to foo.html) so that the web server does not have to compress on-the-fly. nginx supports it[0] and gzip_static does not appear in their nginx config[1]. It might not make a difference if nginx has a in-RAM cache of the compressed files. Otherwise, it has the potential to be pretty significant assuming most requests are made using "Accept-Encoding: gzip" and assuming the web server does not prefer other compression algorithms (eg. Brotli). [0]: https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html https://nginx.org/en/docs/http/ngx_http_gzip_static_module.h... [1]: https://homebrewserver.club/low-tech-website-howto.html#full-nginx-config https://homebrewserver.club/low-tech-website-howto.html#full...

deleted 5y ago
[deleted]
masklinn 5y ago
> maybe using static compression could help. Maybe but that's not a trivial question to answer: the linked article is 236K, gzipping yields 88K (84 at -9, brotly results in 68), so the questions become: * how much energy does the extra 148K (/ 152 / 168) cost, aka once you've factored in the initial handshake what is the efficiency per byte of the transfer * how much does decompression cost on the client side * what is the mix of clients accepting each compression algorithm (and what is the overlap)
lqet 5y ago
Apache also supports this, but the configuration is a bit tricky. For all my private websites, I have a setup where the Apache config filters requests based on the accepted encoding the client sends. For each file, I have three versions on disk: the raw file, a gzipped version, and a brotli-compressed version. Apache picks and sends the correct one. Not only is the file delivered faster, you can also use a higher compression level (gzip with compression level 9 is too slow to be used on each request).
- lambdadmitry 5y ago
  You can also use Zopfli to get a bit higher compression at the expense of longer compression times: https://github.com/google/zopfli https://github.com/google/zopfli

by tleb_ 5y ago

deleted 5y ago

[deleted]

masklinn 5y ago

> maybe using static compression could help. Maybe but that's not a trivial question to answer: the linked article is 236K, gzipping yields 88K (84 at -9, brotly results in 68), so the questions become: * how much energy does the extra 148K (/ 152 / 168) cost, aka once you've factored in the initial handshake what is the efficiency per byte of the transfer * how much does decompression cost on the client side * what is the mix of clients accepting each compression algorithm (and what is the overlap)

lqet 5y ago

Apache also supports this, but the configuration is a bit tricky. For all my private websites, I have a setup where the Apache config filters requests based on the accepted encoding the client sends. For each file, I have three versions on disk: the raw file, a gzipped version, and a brotli-compressed version. Apache picks and sends the correct one. Not only is the file delivered faster, you can also use a higher compression level (gzip with compression level 9 is too slow to be used on each request).

lambdadmitry 5y ago
You can also use Zopfli to get a bit higher compression at the expense of longer compression times: https://github.com/google/zopfli https://github.com/google/zopfli