Below is what I am using on my .htaccess file. The bottom part of the code is what I am using to compress using mod_deflate. There seems to be an issue compressing my php documents, is anyone aware of anything that Freeway could be doing that is stopping the .php from compressing? I’ve tried html, xml and txt, all are being compressed properly.
I have included a link below with the site that won’t compress.
Apache hands off the request for any PHP file to the PHP interpreter,
and I don’t think it ever sees that request again once it does that.
So there probably isn’t any chance for Apache to compress the result,
even though it gets sent to the browser as text/html.
What you may want to do is to look into using an output buffer in PHP
to send gzipped output from your application. Take a look at Tim
Plumb’s Web Fast Action for one example of how to do this.
Walter
On Apr 14, 2011, at 9:12 PM, TeamSDA wrote:
Hi All,
Below is what I am using on my .htaccess file. The bottom part of
the code is what I am using to compress using mod_deflate. There
seems to be an issue compressing my php documents, is anyone aware
of anything that Freeway could be doing that is stopping the .php
from compressing? I’ve tried html, xml and txt, all are being
compressed properly.
I have included a link below with the site that won’t compress.
Thank you for your response. In regards to Tim’s Web Fast action for compressing with PHP, we decided to go with the .htaccess approach for compression as to keep most of our pages .html. Due to forms and other situations some pages must be made a .php.
If we used the .htaccess to compress all other documents, then inside Freeway put the Web Fast action on our .php pages would that cause conflicts in our server for compression?
No, I don’t believe so. The two should not even know of each other’s
presence. Frankly, I’m not sure that the PHP will be much of a
sticking point in terms of file size, you may want to test with and
without Web Fast, because I doubt that you will gain anything unless
there is a LOT of HTML text in that PHP page as viewed from a browser
(the generated HTML, in other words). The setup and teardown time for
the PHP interpreter to generate the page, pipe it to gzip, and then
serve it under gzip headers will likely overwhelm any file-size
savings. On a very-heavily-trafficked site, the bandwidth savings
might come into play, but that’s not likely an issue for you until you
get into Yahoo-home-page scale.
Walter
On Apr 15, 2011, at 10:39 AM, TeamSDA wrote:
Hi Walter,
Thank you for your response. In regards to Tim’s Web Fast action for
compressing with PHP, we decided to go with the .htaccess approach
for compression as to keep most of our pages .html. Due to forms and
other situations some pages must be made a .php.
If we used the .htaccess to compress all other documents, then
inside Freeway put the Web Fast action on our .php pages would that
cause conflicts in our server for compression?
I tested using Tim’s Web Fast action to compress the PHP, it when from 17,422 bytes to 4166 bytes. As you said, no issues seem to be occurring. I’ve included the page I have compressed below. How can I test to make sure there aren’t any issues happening in the background?
You’ll have to do some user testing, make sure that entries are
properly recorded or sent to e-mail or whatever this page does in the
background.
Walter
On Apr 15, 2011, at 1:33 PM, TeamSDA wrote:
Hi Walter,
I tested using Tim’s Web Fast action to compress the PHP, it when
from 17,422 bytes to 4166 bytes. As you said, no issues seem to be
occurring. I’ve included the page I have compressed below. How can I
test to make sure there aren’t any issues happening in the background?