| 3:38 pm on Mar 14, 2011 (gmt 0)|
I'm sorry for this fast second message.
The second pc is my own home pc, both my computers are with same OS, firefox version, pagespeed version. Any tips ?
| 3:57 pm on Mar 14, 2011 (gmt 0)|
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.
| 4:13 pm on Mar 14, 2011 (gmt 0)|
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.
| 4:16 pm on Mar 14, 2011 (gmt 0)|
Thanks. I will ignore it, but one last question:
I still see my css and js like:
If my site is using Gzip arent they supposed to be merged in one file with some kind of .gz ?
| 4:26 pm on Mar 14, 2011 (gmt 0)|
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.
| 4:27 pm on Mar 14, 2011 (gmt 0)|
mark_roach I'm not on proxy.
| 4:30 pm on Mar 14, 2011 (gmt 0)|
|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.
| 4:30 pm on Mar 14, 2011 (gmt 0)|
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.
| 7:34 am on Mar 15, 2011 (gmt 0)|
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.
| 7:56 am on Mar 15, 2011 (gmt 0)|
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.
| 5:58 pm on Mar 15, 2011 (gmt 0)|
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).
| 11:27 am on Mar 18, 2011 (gmt 0)|
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 ?
| 9:19 am on Mar 19, 2011 (gmt 0)|
does the HTTP Response include a "Content-Encoding: gzip" header?
| 12:09 pm on Apr 22, 2011 (gmt 0)|
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.