使用 Gzip 压缩
压缩组件通过减少 HTTP 请求产生的响应包的大小，从而降低传输时间的方式来提高性能。从 HTTP1.1 开始，Web 客户端可以通过 HTTP 请求中的 Accept-Encoding 头来标识对压缩的支持：
Accept-Encoding: gzip,deflateChrome 开发者工具栏监控到如图：
如果 Web 服务器看到请求中的这个头，就会使用客户端列出的方法中的一种来压缩响应。Web 服务器通过响应中的Content-Encoding 头来告知 Web 客户端：
Content-Encoding: gzipChrome 开发者工具栏监控到如图：
目前许多网站通常会压缩 HTML 文档，脚本和样式表的压缩也是值得的（包括 XML 和 JSON 在内的任何文本响应理论上都值得被压缩）。但是，图片和 PDF 文件不应该被压缩，因为它们本来已经被压缩了。
压缩通常能将响应的数据量减少近 70%，但是压缩通常情况下会带来服务端和客户端的 CPU 开销，要检测受益是否大于开销，需要综合考虑响应大小、带宽和客户端服务端物理距离等因素。通常需要对大于 1KB 或 2KB 的文件进行压缩。
当浏览器通过代理来发送请求时，有可能出现浏览器期望接受的压缩后内容和实际接收到的不一致的情况。解决这一问题的方法是在 Web 服务器的响应中添加 Vary 头。Web服务器可以告诉代理根据一个或多个请求头来改变缓存的响应。由于压缩的决定是基于 Accept-Encoding 请求头的，因此需要在服务器的 Vary 响应头中包含 Accept-Encoding:
Vary: Accept-Encoding目前大约 90% 的通过浏览器进行的网络通信都需要使用 gzip，这使得服务端和客户端的对等性变得额外重要。无论是客户端还是服务端发送错误，都会造成页面被破坏。避免错误的一种方式是采用『浏览器白名单』方式，即只为经过证实支持压缩的浏览器提供压缩内容，但是当代理缓存加进来以后，处理边缘情形浏览器将变得更加复杂。另一种方式是使用 Vary: * 或 Cache-Control: private 头来禁用代理缓存。此种方式会为所有浏览器禁用代理缓存，从而增加带宽开销。如何平衡压缩和代理支持需要在加快响应时间、减小带宽开销和边缘情形浏览器缺陷之间进行权衡：
- 如果网站的用户很少，并且他们处于一个小圈子中，边缘情形浏览器不需要太多关注，可以压缩内容并使用
Vary: Accept-Encoding。 - 如果更注重带宽开销，可以和前一种情形一样，压缩内容并使用
Vary: Accept-Encoding。 - 如果网站拥有大量的、多变的用户群，能够应付较高的带宽开销，并且享有高质量的声誉，需要压缩内容并使用
Cache-Control: Private。（ Google 和 Yahoo 都使用这种方式）
关于 LearnKu
粤公网安备 44030502004330号