5 ms·

I've been looking at something similiar for huge static HTML files of autogenerated documentation. I don't see why I can't deflate the tables as javascript dat

by engtech 15y ago

I've been looking at something similiar for huge static HTML files of autogenerated documentation. I don't see why I can't deflate the tables as javascript data and then use JS to inflate and display them. Just playing around with it I was able to compress a 120MB HTML file to 3.5MB.

engtech 15y ago
HTML minifiers/compressors could only get the 120MB HTML file to 104MB.
- dspillett 15y ago
  HTML minifiers don't actually compress in this sense. They remove comments, strip out extraneous whitespace, replace long tags and attributes with equivalent shorter ones (strong->b), normalize markup where possible and so forth. The result is still HTML: no extra decompression step is needed for it to be understood and rendered by any renderer compliant with the standard the tool targets. General compression can get much better results than content translation. Check mod_deflate, mod_gzip, or what-ever your preferred web server's equivalent is (all modern servers aside from those designed to be absolutely minimal (for embedded systems and such) have one).
dspillett 15y ago
Would mod_deflate or equivalent (mod_gzip in older Apache versions, static and dynamic compression can be enabled easily in recent versions of IIS too) not do this for you? If you are worried about the CPU cost of the compression and added request latency, you can pre-compress static content with most modern web servers (see http://stackoverflow.com/questions/75482/how-can-i-pre-compress-files-with-mod-deflate-in-apache-2-x http://stackoverflow.com/questions/75482/how-can-i-pre-compr... for Apache info).
- engtech 15y ago
  In this case, there are no servers. There are only local HTML files that are checked in to revision control and shipped alongside releases. HTML was chosen as the documentation file format because it's easy to find something to view it with.

by engtech 15y ago

engtech 15y ago

HTML minifiers/compressors could only get the 120MB HTML file to 104MB.

dspillett 15y ago
HTML minifiers don't actually compress in this sense. They remove comments, strip out extraneous whitespace, replace long tags and attributes with equivalent shorter ones (strong->b), normalize markup where possible and so forth. The result is still HTML: no extra decompression step is needed for it to be understood and rendered by any renderer compliant with the standard the tool targets. General compression can get much better results than content translation. Check mod_deflate, mod_gzip, or what-ever your preferred web server's equivalent is (all modern servers aside from those designed to be absolutely minimal (for embedded systems and such) have one).

dspillett 15y ago

Would mod_deflate or equivalent (mod_gzip in older Apache versions, static and dynamic compression can be enabled easily in recent versions of IIS too) not do this for you? If you are worried about the CPU cost of the compression and added request latency, you can pre-compress static content with most modern web servers (see http://stackoverflow.com/questions/75482/how-can-i-pre-compress-files-with-mod-deflate-in-apache-2-x http://stackoverflow.com/questions/75482/how-can-i-pre-compr... for Apache info).

engtech 15y ago
In this case, there are no servers. There are only local HTML files that are checked in to revision control and shipped alongside releases. HTML was chosen as the documentation file format because it's easy to find something to view it with.