最近很多IDC服务商以及站点运维团队陆续在服务器端启用了Brotli压缩算法来代替使用多年的Gzip方案。实测结果表明，启用Brotli之后网页静态资源传输体积平均减少了20%左右，页面首屏加载时间明显变短了，在弱网环境下移动端的访问流畅度得到了很大的提升。
Brotli是由Google在2015年推出的，它使用LZ77算法、霍夫曼编码以及二阶上下文建模技术来压缩数据，其中字典包含了超过1.3万个常用的字符串，因此对文本类资源具有天然的压缩优势。同Gzip相比，在相同的压缩级别下，Brotli可以产生更小的文件体积，在中高压缩级别下文本压缩率一般比Gzip高出15%～25%。
实际部署时，HTML、CSS、JavaScript、SVG、JSON等文本资源的压缩效果最好。一张经过Gzip压缩之后大小为85KB的JS文件，切换到Brotli之后一般可以降到65KB到70KB之间；包含大量文字内容的资讯页面整体传输体积下降幅度可以达到两成以上。图片、音视频等已经压缩过的二进制文件不建议再开启Brotli，否则会白白消耗CPU资源而不能减少文件体积。
主流的Web服务器都已经有了成熟的支持。Nginx需要引入ngx_brotli模块，设置brotli on、brotli_comp_level 6等参数；Apache可以通过mod_brotli模块来启用，在配置文件里指定压缩类型和质量等级。同时启用Brotli和Gzip也是常见的做法——服务器会根据浏览器请求头中的Accept-Encoding字段进行协商，不支持Brotli的客户端可以回退到Gzip，兼容性没有问题。
性能取舍上，压缩等级1到6对CPU消耗和Gzip差不多，适用于高并发生产环境；等级9到11虽然可以进一步减少文件大小，但是压缩时间会大大增加，一般只在构建阶段预压缩静态资源时使用。CDN侧也普遍支持Brotli算法，开启之后边缘节点可以直接向支持该算法的客户端提供压缩内容，回源流量和终端加载时间都会降低。
站点管理员在切换压缩算法之后，可以用浏览器开发者工具查看响应头中的content-encoding: br字段来确认是否生效，也可以对比Lighthouse或者WebPageTest的加载时间报告。有站点反馈，在带宽受限的移动网络中，首屏可交互时间的减少幅度比传输体积的减小幅度还要大，说明Brotli对真实用户体验的提升已经超越了单纯的体积数字。
随着Chrome、Firefox、Edge、Safari等主流浏览器都支持Brotli，该算法已经成为了网站性能优化的标准配置之一。对于资讯类、社区类、电商类站点来说，在不改动业务代码的情况下，通过服务器开启Brotli就可以得到大约20%的传输体积下降，投入产出比很高。