I spent numerous hours looking into what appear now to be separate gzipping issues / non-issues with my site.
Continue reading post "#1724"gzip posts
Check request compression savings
Gzip compression is almost universally recommended as a basic step to improving site performance. It basically uses a little bit of extra processing on the server and client to significantly reduce the transfer size of most text responses. In Apache, this is done with mod_deflate (see the H5BP config for an example of how to set this up).
A while back, I was setting gzip up on my server, and wanted a simple way to verify that it was working and check how much transfer was saved. One simple way to verify it is working is with curl on the command line. If you run curl -I -H 'Accept-Encoding: gzip,deflate' example.com and see the header Content-Encoding: gzip, compression is working. To test the transfer savings, I wrote a simple script using PHP’s curl library. It makes a request with and without the Accept-Encoding: gzip,deflate header, and compares the transfer data info provided by curl_getinfo().
On my site, I’m using Apache’s ‘mod_deflate’ and ‘mod_filter’ to compress my compressible responses (mostly text), with a setup based on h5bp’s server config. I got my sites running over HTTPS recently, and today, when looking at my site performance with webpagetest.org, I noticed that my content wasn’t compressing. It was still working fine over HTTP. I noticed in h5bp’s comments that <IfModule mod_filter.c> could be removed in Apache versions below 2.3.x. I removed it, and sure enough, compression was working again. I’m not sure why it’s different depending on what protocol I use. Perhaps Dreamhost has separate versions of Apache running for the two protocols. Or perhaps it’s just something different about the configuration in the virtual hosts. Regardless, it’s working now. I just hope this doesn’t cause problems whenever they move to Apache 2.4.