今天看《Even Faster Web Sites》里面的的Going Beyond Gzipping,觉得写得很细,写个随笔记录下。
这章提到虽然服务端开启了Gzip压缩,但是还是有部分请求(好像大概在10%左右)的输出没有进行压缩。造成这种情况的主要原因不是客户端不支持Gzip,而是代理服务器和一些安全软件修改了请求的Accept-Encoding,或者将Accept-Encoding修改成另外一个名称。他们是基于压缩和解压缩需要消耗CPU资源的考虑。
“The culprits fall into two main categories: web proxies and PC security software.”
文章提到处理这个问题的三种方法:
1.尽量缩小我们的页面代码尺寸(未压缩的)
具体提到的方法有:
1.1 使用事件委托
1.2 使用相对路径
1.3 去掉空格
1.4 去掉属性的引号
1.5 避免内联样式
1.6 为js取别名
2.教育用户
意思就是发现客户端不支持Gzip压缩的时候,友好的提示用户,并告诉原因及可能的解决方案。这点126邮箱的做法有点像。
3. 直接检测客户端是否支持Gzip压缩
方法通过代码输入一个Gzip的文件,在客户如果能正常显示则表明支持Gzip,此时设置一个Cookie,以后的请求就通过Cookie的值判断客户端是否支持Gzip。如果支持则通过代码直接输出Gzip压缩后的数据。
此方法需要考虑成本问题。需要具体分析。
总之,我觉得知道存在这种情况,并理解产生这种问题的原因很重要。我们并不一定要去解决这个问题。此问题是否需要解决需要去具体分析在我们的应用中是否存在这种情况?比例多高?是否值得?