1

What I have tried so far:

  • All variations of modifications and additions to .htaccess gzip relevant sections near the bottom.
  • The Advanced CSS/JS Aggregation module, and all suggested configurations provided in its readme, which either had no effect or (in the case of the "best pagescore configuration) caused the site to never load until I manually disabled the module.
  • All combinations of the above two I can conceive of.
  • Disabled all possible competing modules, including adaptive images, boost and core caching of all kinds besides core aggregation required by the Advanced module.
  • Threw some junk text into the mod-headers section to confirm it is active and received a 500 error. Repeat result for all relevant apache modules.

The aggregation works fine - whatever configuration I use, save the one that killed the site, successfully produces the aggregate files AND their counterpart gz files and places both in the correct folder under default/files. But come time a page is requested, the server refuses to serve the gz files - it will only serve the full files irrespective of the client's request for compressed files. Could this be a server thing despite the relevant Apache modules otherwise being active? What else is there to try? Could it be on the theme layer or something?

  • Please describe how you are testing your setup and how you determine whether the content is served in plain text vs compressed. – znerol May 15 '15 at 16:58
  • I check the aggregation manually with firefox and chrome as well as with external applications such as checkgzipcompression.com. I use two instances of chrome to also check as an aononymous and superuser. I check the files are created properly with Advanced's built in information (on that note, its row on Status Report indicates it should work as intended) and manually with FTP. – Alan Grant May 15 '15 at 17:02
  • Does your cached html get gzipped? – mikeytown2 May 15 '15 at 21:01
  • Please make sure that you are examining requests to your assets (CSS/JS) and not your HTML pages. The latter are not compressed unless you enable page caching for anonymous users. Another option is to enabled compression in your webserver (mod_deflate in apache). – znerol May 16 '15 at 13:38
  • 1
    Also note that checkgzipcompression.com does not seem to be reliable. E.g., it reports that drupal.org is not using gzip (neither for HTML nor for assets), which clearly is wrong (the Content-Encoding response header is set to gzip there). – znerol May 16 '15 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.