Comments on: Who’s not getting gzip?

By: Steve Souders

Steve Souders — Wed, 04 Jan 2012 20:41:06 +0000

@Ezhil: Your best bet is to search the support docs for your webhosting provider – or switch providers!

By: Ezhil

Ezhil — Tue, 20 Dec 2011 06:50:10 +0000

@steve: We tried to gzip our files in our website( wordpress powered ), but as we are using shared hosting, the hosting provider doesn’t support gzipping of files. This causes our website more than a 500kb of performance downgrade. would you be kind enough to explain what are the guidelines for gzip, one should follow in shared hosting.

By: Steve Souders

Steve Souders — Wed, 29 Sep 2010 22:59:28 +0000

@Dean: The point of that test is to tell users (like yourself) if they’re browser is suffering because compression is disabled. Compression is disabled in browsers when users are behind proxies or have anti-virus software that masks the Accept-Encoding header. It sounds like that’s exactly what you’ve discovered – your corporate firewall has disabled compression, so servers are sending you uncompressed responses resulting in a slower experience.

By: Dean Landolt

Dean Landolt — Wed, 29 Sep 2010 22:17:31 +0000

Just a heads up: that browser compression test page you linked to? It’s lying. It’s showing no accept-encoding header for me in every browser I tested. I figured our corporate firewall was misconfigured so I wrote my own little detection script and sure enough, chrome is sending “gzip,deflate,sdch” and firefox 4 beta “gzip, deflate”.

By: Melvin

Melvin — Thu, 11 Feb 2010 15:28:32 +0000

Oops I’ve now read to the bottom of that httpwatch post and see that you’ve commented on #3 about cache-control: public !

By: Melvin

Melvin — Thu, 11 Feb 2010 15:25:10 +0000

Hi Steve,

In your book you suggest creating a gzip whitelist of browsers, and setting cache-control: Private to prevent proxies from caching and then delivering the wrong version of zipped/unzipped pages to browsers.

However I have come across an article that suggests that when using SSL, Firefox will not use persistent caching unless cache-control:public is set. See #3 on http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

This would require a different setup for SSL and non-SSL pages.
I would be great to hear your opinion on this.

Thanks
Melvin

By: Kennedy

Kennedy — Sat, 21 Nov 2009 18:36:32 +0000

I just made a post on how to gzip your site, thought I would share. http://kennedysgarage.com/compress-components-with-gzip/

By: sparetimeadmin

sparetimeadmin — Wed, 18 Nov 2009 22:53:54 +0000

Thanks for the fast reply. Your books are on my list for a long time already. It’s about time, I guess. :)

By: Steve Souders

Steve Souders — Wed, 18 Nov 2009 17:47:39 +0000

@sparetimeadmin: Years ago this was an issue, but not so much now. You could use a whitelist approach. See Chapter 4 of High Performance Web Sites (page 34).

By: sparetimeadmin

sparetimeadmin — Tue, 17 Nov 2009 18:44:09 +0000

Is there anything that speaks against enabling mod_deflate or similar in servers? People I work with say they won’t enable those modules because “they had problems with several clients” or with “mobile or proxy users”. Is that still a problem nowadays? Nonworking, garbled sites due to enabling those modules are obviously not acceptable (even when it’s like 0.2% of the visitors).

I’m thinking about cases where:
- browsers accept gzipped content, but don’t work properly when they receive it
- proxy servers (or similiar) fiddling around with headers so that browsers get compressed content when they only understand uncompressed one
- mobile browsers send certain headers, but won’t work at all with gezipped content
- etc.pp.

Are there ANY hints, why enabling mod_deflate and the like would be counter-productive and would not work for certain clients. (I’m talking about non-working sites – not uncompressed, but still working sites)

Thanks in advance.