Page speed gzip confusion

[memario]

Hey guys
Almost to the top with "Page Speed Score: 95/100" but almost.
"...with gzip could reduce their transfer size by 222.7KiB (70% reduction)."
I'm using joomla cms which has a Gzip funcion, after turning it on, page speed still complains. I turned that down. Then I used my host provider option for gzip - the same. Then I've insert varius lines in .htaccess (tryed in both the root and in the js folder) - no result. I found a site which tells you if you have a GZip on. It says I do. I even cleared all of firefox history - nada. Whats going on? Does page speed tool lie? I somehow doubt. So any recommendation are mostly appreciated.
Best regards,
Mario

[memario]

I'm sorry for this fast second message.
I just cheked the site on another computer. Damn wierd. There I have 92/100 but "Enable compression" is green (100/100). The reason of 92/100 is "Inline Small CSS" and "Inline Small JavaScript". I guess that when Gzip is on, page speed says this for reducing http requests. I think thats stupid. I wont have 100/100 because of that (I'know its not that important and I'm not fanatic about it, but still). Anyway, I'm not so much concerned about the inline recommendations, but why I see two different page speed results?
The second pc is my own home pc, both my computers are with same OS, firefox version, pagespeed version. Any tips ?

[wheel]

Turn gzipping on at the host level and forget about it. Gzipping isn't perfect in 100% of cases, but it's almost perfect in 99% of cases just by having it turned on.

You're more likely wasting time figuring out idiosyncracies of the measuring tool. And that's going to be futile - and pointless even if you do.

[mark_roach]

Do you go through a proxy server ?

I don't know much about proxies, but could the proxy be turning off the gzip request ?

I have just been testing my browser at browserscope.org and it reported that my broswer did not support compression when I know it does. I go through a proxy here and wonder if that is causing the problem.

[memario]

Thanks. I will ignore it, but one last question:
I still see my css and js like:
domain.com/css_folder/style.css
domain.com/js_folder/javascript.js
If my site is using Gzip arent they supposed to be merged in one file with some kind of .gz ?

[BillyS]

BTW - make sure you're not double compressing with Joomla. There are tools that will tell you the information is compressed, but it's not in all browsers. It depends on how much control you have over your host's server. It took me several weeks of trial and error before I finally figured out what was happening.

Good luck!

[memario]

mark_roach I'm not on proxy.

[wheel]

If my site is using Gzip arent they supposed to be merged in one file with some kind of .gz ?

No. It's transparent. Your webserver gzips the file,then in the headers says 'this is compressed'. The browser gets the file, and unzips it. It's seamless and is not exactly like the process you see when you zip a directory on your desktop.

[memario]

BillyS, when I was testing the differnet ways for gzip (host,jooml,plugin for joomla,htaccess) I used only one at a time. I'm now leaving my work place, and visit the topic tommorow. Thanks for all comments.

[mark_roach]

I'm not on proxy

I am no expert in this area but I suspect every web request goes through some form of proxy server. For example your ISP will use a proxy.

I have just run a pagespeed test on a laptop using two different network connections. One reported that GZIP was used, the other said it wasn't.

Browserscope also confirmed these findings.

[memario]

mark_roach thanks for the info. I hope that page speed will fix this anomaly. As for now I wont pay attention to its gzip recommendation.

[ergophobe]

You want to check this by checking headers.

Unfortunately, some anti-virus software (Symantec, Norton for sure, at least on my computers) will strip the browser request header saying that the browser will accept gzip. This is because these AV companies believe that it will bog down your CPU uncompressing everything before doing on-the-fly AV checking (charitable explanation) or are too damn lazy to design their programs right (my explanation).

So if you are using a local app to check for compression, results will be subject to the vagaries of your computer setup. Better off to use a site designed for testing compression. Then you know what the server sends by default.

You can force gzip compression on the 10-20% who have it disabled b/c of their AV setup. This is what Google does. Essentially, you set a cookie, but the cookie data is gzipped. Then on subsequent page loads you see if the cookie is present. If it is, then ipso facto, the client can accept gzipped content regardless of how the headers are being mangled by Norton, and you send it to them, whether they asked for it or not.

If you have lots of traffic, that may be worth it (imagine the bandwidth Google saves by gzipping the 10% who could receive gzipped content but don't ask for it explicitly).

[memario]

Hey guys I'm back to the topic.
I found this code on two different articles for joomla gzip compression.
<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>

When I place this in the begining of the <head> I can't access my page. firefox says:
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
But the page speed tool removes the "Enable compression" warning.
When I remove the code, I can access the website but the page speed warning is back. Can you explain to me what is this code doing ? And overall what is going on ?

[phranque]

does the HTTP Response include a "Content-Encoding: gzip" header?

[enigma1]

The php ob_start switches buffering on. Using ob_start("ob_gzhandler") may cause problems if you're caching content with a 304 header as in these cases no content will be sent by the server but because of the ob_gzhandler the browser may think the content is corrupt. Best to use the default ob_start() and then gzip the buffer.

these AV companies believe that it will bog down your CPU uncompressing everything before doing on-the-fly AV checking (charitable explanation) or are too damn lazy to design their programs right (my explanation).

Which is unfortunate but the same happens with various proxies isps deploy to send all resources as compressed content the the client breaking js and css and making pages unreadable. I wouldn't workaround breaking the http spec by sending cookies. Let them fix their code.