4 ms·
The article explicitly states that it is trying to find out which algorithm is optimal for small text-based documents that are common on the web, such as CSS, J
by kijin 11y ago
The article explicitly states that it is trying to find out which algorithm is optimal for small text-based documents that are common on the web, such as CSS, JS, and HTML.
The best compression algorithm for small text files might be very different from the best algorithm for large amounts of general data. If your browser needs to decompress 100 separate files in a fraction of a second, startup time does matter.
- joosters 11y agoFair enough, but if you want to compress CSS, JS and HTML then why not test it on those? It also depends upon how you are supplying the compressed data. For static files, the compression time might not even matter - the web server can cache all the compressed versions and the compression performance is minimised. For dynamic data (e.g. the output of a PHP or whatever), you might also want to test how well the compressors handle streaming data, e.g. feeding parts of a page piecemeal into the compressor and directly sending the output to the client packet by packet. Some compression systems handle this extremely badly.