YSlow给F等级使用mod_deflate压缩的文件 [英] YSlow gives F grade to files compressed with mod_deflate

问题描述

我在 Apache 2.2 上使用 mod_deflate ，压缩级别设置为9.我已根据以下建议对网站的各个方面进行了微调： YSlow（v2），并且已成功获得总体A成绩（总分：91）以及所有类别，除了：

• 减少HTTP请求（成绩C -
  我仍​​在继续努力进行
  图像统一）


• 使用gzip压缩组件（ Grade
  F ）

YSlow仍然会报告F并告诉我在我的CSS和JS文件使用gzip。这里是YSlow报告的屏幕截图（为了隐私的目的，域已经被模糊了）：

但是， GIDNetwork GZIP Test 报告完全压缩！

mod_deflate我的.htaccess

 ＃下面使用mod_deflate来压缩文本文件。不要压缩二进制文件。 
< IfModule mod_deflate.c> 
 SetOutputFilter DEFLATE 
 
＃压缩类型为html，text，js和css的内容
 AddOutputFilterByType DEFLATE text / html text / plain text / css text / javascript text / xml image / svg + xml应用程序/ javascript应用程序/ x-javascript应用程序/ atom_xml应用程序/ rss + xml应用程序/ xml应用程序/ xhtml + xml应用程序/ x-httpd-php应用程序/ x-httpd-fastphp 
 
＃正确处理不支持压缩的旧浏览器
 BrowserMatch ^ Mozilla / 4 gzip-only-text / html 
 BrowserMatch ^ Mozilla / 4 \.0 no-gzip 
 BrowserMatch \\ \\ bMSIE！no-gzip！gzip-only-text / html 
 
＃显式地从压缩中排除二进制文件，以防万一
 SetEnvIfNoCase Request_URI \。（?: gif | jpe？ png）$ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \。（？：exe | t？gz | zip | bz2 | sit | rar）$ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \ .pdf $ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \.avi $ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \.mov $ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \\ \\.mp3 $ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \.mp4 $ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI \.rm $ no-gzip dont-vary 
 
＃正确处理来自代理后面的请求
头附加Vary User-Agent env =！dont-vary 
< / IfModule> 
  

任何人都可以指出我出错的地方吗？

谢谢，
m ^ e

解决方案

mod_deflate可能已配置不正确。 p>

典型的mod_deflate配置可能会排除基于用户代理字符串的某些浏览器，并且可能只能配置为压缩某些文件类型 - 由服务器上注册的MIME类型标识。

您应该压缩所有的HTML，CSS和Javascript文件，而不是您的PNG，GIF或JPEG文件，并有Netscape 4的错误，你可以可能不想解释。尝试使用文档中的示例代码：

 < Location /> 
＃插入过滤器
 SetOutputFilter DEFLATE 
 
＃Netscape 4.x有一些问题... 
 BrowserMatch ^ Mozilla / 4 gzip-only-text / html 
 
＃Netscape 4.06-4.08有更多的问题
 BrowserMatch ^ Mozilla / 4 \.0 no-gzip 
 
＃MSIE伪装成Netscape，但它是罚款
 BrowserMatch \bMSIE！no-gzip！gzip-only-text / html 
＃不压缩图像
 SetEnvIfNoCase Request_URI \ 
 \。 gif | jpe？g | png）$ no-gzip dont-vary 
 
＃确保代理不会提供错误的内容
头添加Vary User-Agent env =！dont-vary 
< / Location> 
  

注意，你发布的GIDZipTest GZIP测试不会测试相关的Javascript和CSS文件， - 在GIDZipTest GZIP测试，你需要单独测试这些。

我想你的ISP也可能是使用缓存代理 - 透明或不透明 - 这是修改或删除您的Accept-Encoding：头。要规则这是因为你可以让别人从你的ISP外部测试。

另一件要注意的是，当使用gzip压缩文件时，你交易带宽为CPU时间。在较低的压缩强度之上，您将看到减少的带宽节省的回报，但是所需的CPU时间的巨大增加。不幸的是，压缩强度高达9，你几乎肯定浪费太多的CPU时间为非常小的改进压缩 - 我总是建议使用强度1。

I'm using mod_deflate on Apache 2.2 and the compression level is set to 9. I've fine tuned every possible aspects of the site based on the recommendations of YSlow (v2) and have managed to get an overall A grade (Total Score: 91) as well as on all categories except for:

• Make fewer HTTP requests (Grade C - I'm still working on further unification of images)
• Compress components with gzip (Grade F)

YSlow still reports back with a F and tells me to use gzip on my CSS and JS files. Here's a screenshot of the YSlow report (the domain has been blurred out for the sake of privacy):

However, sites like GIDNetwork GZIP Test reports perfect compression!!

mod_deflate section of my .htaccess

# Below uses mod_deflate to compress text files. Never compress binary files.
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE

# compress content with type html, text, js, and css
AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript text/xml image/svg+xml application/javascript application/x-javascript application/atom_xml application/rss+xml application/xml application/xhtml+xml application/x-httpd-php application/x-httpd-fastphp

# Properly handle old browsers that do not support compression  
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Explicitly exclude binary files from compression just in case
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary

# properly handle requests coming from behind proxies
Header append Vary User-Agent env=!dont-vary
</IfModule>

Can anyone please point out where I'm going wrong?

Thanks, m^e

解决方案

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.

这篇关于YSlow给F等级使用mod_deflate压缩的文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！