ansaurus

Question

YSlow gives F grade to files compressed with mod_deflate

Answer 1

+2 A:

It's possible that mod_deflate has been configured incorrectly.

A typical mod_deflate configuration may be excluding certain browsers based on user-agent strings, and may only be configured to compress certain file types - identified by their MIME type as registered on the server.

You should be compressing all of your HTML, CSS and Javascript files, but not your PNG, GIF or JPEG files, and there are bugs with Netscape 4 you may or may not want to account for. Try using the sample code from the documentation:

<Location />
    # Insert filter
    SetOutputFilter DEFLATE

    # 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
    # Don't compress images
    SetEnvIfNoCase Request_URI \
    \.(?:gif|jpe?g|png)$ no-gzip dont-vary

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

Note too that the GIDZipTest GZIP test you posted does not test associated Javascript and CSS files, whereas YSlow does - in GIDZipTest GZIP test you'd need to test these individually.

I guess it is also possible that your ISP is using a caching proxy - transparent or not - which is mangling or removing your Accept-Encoding: header. To rule this out as the cause you could get someone to test it from outside of your ISP.

Another thing to note is that when compressing files using gzip you are trading bandwidth for CPU time. Above the lower compression strengths you will see diminishing returns in bandwidth savings, but huge increases in CPU time required. Unfortunately with a compression strength as high as 9, you are almost certainly wasting too much CPU time for very little improved compression - I would always recommend using strength of 1.

thomasrutter 2009-06-10 06:56:57

I've added the deflate portion of my htaccess above... it more or less matches the example you've shown here. As for the CPU time, we're running on a dedicated server with no other processes (except for MySQL) running along with Apache. Should the CPU utilization be of concern in such a scenario ?

miCRoSCoPiC_eaRthLinG 2009-06-10 08:30:20

As for the GIDZipTest, I followed your suggestion and checked for compression on the JS and CSS files individually instead of the whole page... and it reported a compression of 70% and 77.3% respectively.

miCRoSCoPiC_eaRthLinG 2009-06-10 08:35:53

Is it possible that on Firefox, you are accessing the site through a proxy? It's possible that a proxy could be dropping the Accept-Encoding: header that your browser sends, in order to cache it (the proxy could also be transparent). Getting someone from outsite your ISP to check it with their own Firefox would confirm or rule that out as the cause.

thomasrutter 2009-06-10 23:13:41

I'd completely forgotten about this post... as midway my problem got solved. Indeed it was due to a proxy employed at my workplace. They got rid of it and all was fine :) Thanks for all the help..

miCRoSCoPiC_eaRthLinG 2009-07-30 05:22:03

Answer 2

+2 A:

To do the same with ASP.NET read this article - http://coder.informisk.com/post/2010/01/10/Get-Grade-A-in-YSlow.aspx

sam 2010-01-10 14:38:34

thanks for the info. I was beginning to wonder :)

miCRoSCoPiC_eaRthLinG 2010-01-11 11:35:54

Answer 3

+1 A:

this website http://www.rubyrobot.org/article/5-tips-for-faster-loading-web-sites told me that AddOutputFilterByType will not work in .htaccess

bengkoang 2010-03-23 15:58:49

ansaurus

tags:

views:

answers:

YSlow gives F grade to files compressed with mod_deflate

related questions