Issues with gzip compression – mod_deflate

I'm getting this error on my site...

- Your server may not have the "deflate" module enabled (mod_deflate for Apache, ngx_http_gzip_module for NGINX)
- Another plugin may be interfering with the configuration

I've tried deactivating all the plugins to check that and no joy. I've also added this to my .htaccess file...

AddOutputFilterByType DEFLATE text/html text/plain text/xml
AddOutputFilterByType DEFLATE text/css application/x-javascript
AddOutputFilterByType DEFLATE text/css text/html text/plain text/xml text/javascript

which my server (MediaTemple) tells me should enable mod_deflate. It's just text/javascript that is currently showing 'disabled'.

Any ideas?

  • Adam Czajczyk

    Hello Jon,

    I hope you're well today and thank you for your question!

    I understand that your host confirmed already that the "mod_deflate" module is available, enabled and configured on your server. The code that you host suggested to be added to the .htaccess file however doesn't seem to be correct.

    Please try replacing this line:

    AddOutputFilterByType DEFLATE text/css application/x-javascript

    with this one

    AddOutputFilterByType DEFLATE text/javascript application/x-javascript

    Let me know if that worked for you, please.

    Best regards,
    Adam

  • Adam Czajczyk

    Hello Jon,

    Thank you for your replay.

    Would you mind sharing entire content of your .htaccess file with me here?

    It would also be great if you could get in touch with your host once again and get a confirmation from them that text/javascript compression is for sure supported by the server. I know they suggested the code but I also know that there's been cases where host simply shared the "universal" code but then it turned out that Apache was simply not set to handle compression of that type of content. It would be good to know that for sure.

    Best regards,
    Adam

  • Jon

    I'll check with them on the text/javascript thing. They sent this prior to that request in case it helps...

    <quote>
    Based on the headers returned for anderchurch.org.uk.s218979.gridserver.com, it can be confirmed that mod_deflate is enabled and being used on the Grid. The "Content-Encoding" header below is the one that shows this.

    $ curl -IH 'Accept-Encoding: gzip,deflate' anderchurch.org.uk.s218979.gridserver.com
    HTTP/1.1 301 Moved Permanently
    Date: Fri, 24 Feb 2017 23:32:35 GMT
    Server: Apache/2.2.22
    X-Powered-By: PHP/5.6.21
    Location: http://ninefootone.co.uk.s218979.gridserver.com/
    Vary: User-Agent,Accept-Encoding
    Content-Encoding: gzip
    Content-Length: 20
    Content-Type: text/html; charset=UTF-8

    You may also use the following third-party site to verify this: http://www.gidnetwork.com/tools/gzip-test.php

    If you have questions about the information within this support request or any of your (mt) Media Temple services, please feel free to contact us at any time. We are here 24/7 to assist you. Thank you for choosing (mt) Media Temple for your hosting needs.
    </quote>

  • Jon

    And here's my .htaccess file...

    --

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    # END WordPress

    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/javascript application/x-javascript
    AddOutputFilterByType DEFLATE text/css text/html text/plain text/xml text/javascript

    # BEGIN WP-HUMMINGBIRD-GZIP

    <IfModule mod_deflate.c>
    <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
    SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
    RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
    </IfModule>
    </IfModule>
    <IfModule mod_filter.c>
    AddOutputFilterByType DEFLATE "application/atom+xml" \
    "application/javascript" \
    "application/json" \
    "application/ld+json" \
    "application/manifest+json" \
    "application/rdf+xml" \
    "application/rss+xml" \
    "application/schema+json" \
    "application/vnd.geo+json" \
    "application/vnd.ms-fontobject" \
    "application/x-font-ttf" \
    "application/x-javascript" \
    "application/x-web-app-manifest+json" \
    "application/xhtml+xml" \
    "application/xml" \
    "font/eot" \
    "font/opentype" \
    "image/bmp" \
    "image/svg+xml" \
    "image/vnd.microsoft.icon" \
    "image/x-icon" \
    "text/cache-manifest" \
    "text/css" \
    "text/html" \
    "text/javascript" \
    "text/plain" \
    "text/vcard" \
    "text/vnd.rim.location.xloc" \
    "text/vtt" \
    "text/x-component" \
    "text/x-cross-domain-policy" \
    "text/xml"

    </IfModule>
    <IfModule mod_mime.c>
    AddEncoding gzip svgz
    </IfModule>

    </IfModule>
    # END WP-HUMMINGBIRD-GZIP

  • Adam Czajczyk

    Hello Jon!

    Thank you for your replay.

    The .htaccess seems fine in my opinion. I think however it'd be worth "pushing" the host a bit. I admit I'm slightly surprised with their response because they checked your site by first fetching it with "cUrl" (it's pretty much the same as trying that in browser) and then with external tools instead of checking server configuration.

    The thing is they are partially right with that replay. The site is compressed and the "Content-Encoding" header is returned because the main content of (each) site is HTML. Compression for that type of content is enabled.

    Digging a bit deeper - for example with Chrome's Dev Tools (Network analysis) - shows clearly that resources of "CSS" and "Doc" (text, html) type are compressed, they do have "Content-Encoding: gzip" header which confirms that. The "JS" resources are not (no "Content-Encoding: gzip").

    That actually means two things: 1) the "mod_defalte" is working because CSS and HTML are compressed 2) the .htaccess rules are working too (because they do enable compression). My point is: I'm pretty sure that it's the matter of server configuration or some very unusual .htaccess rule is necessary.

    Since you are going to ask them specifically about text/javascript, let me know what was their response please.

    Kind regards,
    Adam

  • Adam Czajczyk

    Hello Jon!

    Thank you for letting me know about host response. I have once again audited the site, digging even deeper and I found out that we might have been on a wrong track with this.

    It turns out that some of the JS resources are actually compressed. Most of them are not but several files are properly served as gzip compressed. Further search revealed that the case here seems to be that those other files are "versioned", most likely on purpose. What I mean is that there's a special query string included that should prevent these files from being cached.

    This is most likely done by the theme and/or plugins that generate some of these files. While it should affect caching rather than compression it happens that it's just these files that are not served as gzipped so I think that would be the reason here.

    Why that happens? It seems that the most recent answer from your host is a clue here. They include "application/x-javascript" type there but from their response it looks like they don't include "text/javascript". Those "versioned and not versioned" files seem to be treated differently so I'd try to remove those "version queries" from them.

    Give this plugin a try please:

    https://wordpress.org/plugins/remove-query-strings-from-static-resources/

    Install it please and run "re-check" on Hummingbird -> Gzip compression page. If that still doesn't show "text/javascript" to be enabled, let me know please and I'll check if despite Hummingbird reports those resources are compressed or not.

    Kind regards,
    Adam

  • Adam Czajczyk

    Hello, Jon!

    I sincerely apologize for such a delay in my reply.

    It seems that the issue might be caused by server configuration after all because it looks that the site returns "application/javascript" as content type while the compression goes for "application/x-javascript" type. Server should allow compressing "application/javascript" MIME type as well in order for compression to work fine, according to one of our developers who reviewed this thread.

    In one of your previous posts (here: https://premium.wpmudev.org/forums/topic/issues-with-gzip-compression-mod_deflate?ptm=c&utm_expid=3606929-108.O6f5ypXuTg-XPCV9sY1yrw.2#post-1222834) your host explicitly stated that the content type is "application/x-javascript" so could you please ask them if they could also allow "application/javascript"?

    Once again, I apologize for the delay on my side.

    Kind regards,
    Adam

  • Waldbär

    Maybe the problem is already solved, but there are still users with the same probs.
    I have fixed the html - compression / deflate prob by "try and error".
    After long tests with htaccess, google sessions and some tickets to my hoster, it was a stupid one.
    For me it was an activated Maintenance / Comming soon plugin.
    After switching off, Hummigbird was able to perform the gzip - compression in all three disciplines easily.
    Maybe it works for others!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.