gzip not working for 2 file types

Hi @nanny7,

GZIP Compression is a server-side thing and Hummingbird simply tries to enable it by applying the .htaccess rules, however, in order for this to work your host needs to be allowing the changes to be applied.
Some hosts have predefined GZIP values on their servers and don’t allow them to be changed via .htaccess.

Can you check with your hosting provider if they allow these changes to be made via .htaccess rules and if not if they can change their predefined values to allow it for all file types listed in Hummingbird.

If you’re still having issues after that please share the URL of your site so we can check the reports in GZIP checker.

Cheers,
Predrag

Hi I keep getting the same answer from the host saying that they have gzip enabled and ignore me asking about apache.
I did notice this htaccess file in my host directory, would it be the culprit?

<IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    <IfModule mod_setenvif.c>
        # Netscape 4.x has some problems...
        BrowserMatch ^Mozilla/4 gzip-only-text/html

        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4\.0[678] no-gzip

        # MSIE masquerades as Netscape, but it is fine
        # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

        # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
        # the above regex won't work. You can use the following
        # workaround to get the desired effect:
        BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

        # Don't compress images
        SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
    </IfModule>

    <IfModule mod_headers.c>
        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

Hello @nanny7,

The above set defines cases, where gzip should not be implemented and add a condition where and how to gzip, should be implemented for specific cases.

Those cases are defined for Netscape, Internet Explorer, Microsoft Edge and Mozzila browsers.

The following case gives an instruction to not compress gif, jpeg and png files:

# Don't compress images
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary

Can you take a backup of your htaccess file and remove the case I have stated above and below then check if things look good to you?

 # Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

Do let me know how that goes with the change.

Thank you,
Prathamesh Palve

Hello @nanny7,

Just to add to the above reply, do you see Gzip for CSS and JS off in the Hummingbird-> Gzip Compression section? If not, I see that tool like this (https://www.giftofspeed.com/gzip-test/) would just gzip for txt. HTML and not for CSS and JSS. To check the CSS and JSS, you would need to check the specific CSS or JS file to be double sure. Could you check the same once and let me know what that reports? Also, if you are comfortable, could you also share the site URL to pull out a few tests to check the same on our end?

Thank you,
Prathamesh Palve

Hi I just a hash in front of the image section is this correct?

<IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    <IfModule mod_setenvif.c>
        # Netscape 4.x has some problems...
        BrowserMatch ^Mozilla/4 gzip-only-text/html

        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4\.0[678] no-gzip

        # MSIE masquerades as Netscape, but it is fine
        # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

        # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
        # the above regex won't work. You can use the following
        # workaround to get the desired effect:
        BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

        # Don't compress images
       # SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
    </IfModule>

    <IfModule mod_headers.c>
        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

It is still the same. I have no clue how to test for gzip online for css and javascript I can’t find a tool. This is the site: Site

Hello @nanny7,

I went ahead and tested your site with the CSS and JS links and I see it working well. Here are the results

Test to check Gzip for JS

URL: https://www.websitescreated.com.au/webdesigner/js/customise.js
Brotli Is Enabled
Original Size:
2.9 KB
Brotli Size(compressed):
817 B
Compression %:
72.95% is compressed
More Information
HTTP Status:
200 OK
Request Time:
1259 ms
Content-Type:
application/javascript
Server:
LiteSpeed

Test to check Gzip for CSS

URL: https://www.websitescreated.com.au/assets/hummingbird-assets/3f5c24f16532ce6efa4573cba4816527.css
Brotli Is Enabled
Original Size:
998 B
Brotli Size(compressed):
246 B
Compression %:
75.35% is compressed
More Information
HTTP Status:
200 OK
Request Time:
610 ms
Content-Type:
text/CSS
Server:
LiteSpeed

This means the Gzip is working as expected. You can check the same using the URLs’s I have listed with the same tool you used before. Where do you see it not working properly? Do you see that in the Hummingbird-> GZIP section? Do let me know about it.

Thank you,
Prathamesh Palve

• This reply was modified 4 years, 2 months ago by Saurabh - WPMU DEV Support. Reason: Added more instructions

Hi thanks for that I have added an image for you to see it is in humminbird gzip compression section:Link

Hi @nanny7

I hope you’re well today!

I think there’s a bit of “simplification” that “sneaked in” into this thread so let me explain that.

As mentioned before, GZIP compression is a “server-side thing” which means it’s performed by the webserver (Apache, Nginx or other). Hummingbird (and other plugins for that matter) can only control it – whether it’s enabled or not for certain MIME (content) types. That is, if host allows that (most do).

This is what rules added to .htaccess by Hummingbird do.

There are cases, however, when either host simply “ignores” that (so compression configuration is “set in stone” in some configuration by host) or there’s some issue that “breaks” it or e.g. there’s proxy/CDN that “overwrites” compression headers.

In this case it seems we are dealing with a different thing. Hummingbird reports that GZIP compression is disabled for JS and CSS and… that actually is also true because the compression that is enabled is not GZIP but Brotli.

It’s got the same “goal” serves pretty much the same purpose but it’s a different compression type, algorithm-wise. It’s fine to have it instead of “standard” GZIP. The reason why Hummingbird so far checks/helps with GZIP is that is more common and widely available while Brotli – being supported by all modern browsers – is still relatively new and not as widely available as GZIP.

I see that my colleague earlier confirmed that GZIP is working fine while his test results (that he quoted above) clearly state “Brotli” compression but it wasn’t intentional as he focused primarily on compression itself as this is the most important thing in this case – whether it’s Brotli or GZIP is secondary issue. In fact, Brotli is newer and considered to be faster/more efficient in many cases. I apologize for causing confusion there!

So, Brotli is perfectly fine to use instead of GZIP but it might lead to unexpected detection issues in Hummingbird as it simply doesn’t support it yet. We are already planning to add full Brotli support in future so it would be able to “control” it and also to avoid any “inconclusive”/”false” check results. I don’t have an ETA on this but it’s already on a planned features list.

Kind regards
Adam

thanks for the explanation

Hello @nanny7,

I completely apologise for the confusion caused initially. Also, as the compression seems to be happening correctly and things look good, I would be marking this resolved. But, should you have any doubts or need any help, feel free to reply to us here or open a fresh thread and we would be happy to help.

Thank you,
Prathamesh Palve