「简明性能优化」双端开启Gzip指南
- 2019 年 10 月 4 日
- 笔记
本文目录:
- 开启gzip压缩的好处
Webpack
的gzip
设置Nginx
的gzip
设置- 如何验证
gzip
? - 双端Gzip的区别和意义
1. 开启gzip压缩的好处
可以减小文件体积,传输速度更快。gzip是节省带宽和加快站点速度的有效方法。
- 服务端发送数据时可以配置
Content-Encoding:gzip
,用户说明数据的压缩方式 - 客户端接受到数据后去检查对应字段的信息,就可以根据相应的格式去解码。
- 客户端请求时,可以用
Accept-Encoding:gzip
,用户说明接受哪些压缩方法。
在 http/1.0 协议中关于服务端发送的数据可以配置一个 Content-Encoding
字段,这个字段用于说明数据的压缩方法
Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate
客户端在接受到返回的数据后去检查对应字段的信息,然后根据对应的格式去做相应的解码。客户端在请求时,可以用 Accept-Encoding 字段说明自己接受哪些压缩方法。
Accept-Encoding: gzip, deflate

2. Webpack
的 gzip
设置
这里使用的插件为: CompressionWebpackPlugin
const CompressionWebpackPlugin = require('compression-webpack-plugin') module.exports = { “plugins”:[new CompressionWebpackPlugin] }
官方文档
具体配置:
const CompressionWebpackPlugin = require('compression-webpack-plugin'); webpackConfig.plugins.push( new CompressionWebpackPlugin({ asset: '[path].gz[query]', algorithm: 'gzip', test: new RegExp('\.(js|css)$'), // 只处理大于xx字节 的文件,默认:0 threshold: 10240, // 示例:一个1024b大小的文件,压缩后大小为768b,minRatio : 0.75 minRatio: 0.8 // 默认: 0.8 // 是否删除源文件,默认: false deleteOriginalAssets: false }) )

开启gzip前

开启gzip后
gzip
后的大小从277KB到只有~91.2KB!
3. Nginx
的 gzip
设置
打开 /etc/nginx/conf.d
编写以下配置。
server { gzip on; gzip_static on; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; gzip_proxied any; gzip_vary on; gzip_comp_level 6; gzip_buffers 16 8k; # 注:99.99%的浏览器基本上都支持gzip解压了,所以可以不用设这个值,保持系统默认即可。 gzip_http_version 1.1; ... }
gzip on|off
:
- 默认值: gzip off
- 开启或者关闭gzip模块
gzip_static on|off
:
nginx
对于静态文件的处理模块- 该模块可以读取预先压缩的gz文件,这样可以减少每次请求进行gzip压缩的CPU资源消耗。
- 该模块启用后,
nginx
首先检查是否存在请求静态文件的gz结尾的文件,如果有则直接返回该gz文件内容。为了要兼容不支持gzip的浏览器,启用gzip_static
模块就必须同时保留原始静态文件和gz文件。这样的话,在有大量静态文件的情况下,将会大大增加磁盘空间。我们可以利用nginx的反向代理功能实现只保留gz文件。
gzip_types mime-type[mime-type...]
:
nginx
作为反向代理的时候启用,开启或者关闭后端服务器返回的结果,匹配的前提是后端服务器必须要返回包含"Via"的header头
。- 默认值:
gzip_types text/html
(默认不对js/css文件进行压缩) - 压缩类型,匹配MIME类型进行压缩
gzip_proxied[off|expired|no-cache|no-store]...
:
off
– 关闭所有的代理结果数据的压缩no-cache
– 启用压缩,如果header头中包含 "Cache-Control:no-cache
" 头信息
gzip_vary on|off
:
- 和
http
头有关系,加个vary
头,给代理服务器用的,有的浏览器支持压缩,有的不支持,所以避免浪费不支持的也压缩,所以根据客户端的HTTP
头来判断,是否需要压缩
gzip_comp_level
:
- 默认值:1(建议选择为4~6)
gzip
压缩比/压缩级别,压缩级别1-9,级别越高压缩率越大,当然压缩时间也就越长(传输快但比较消耗cpu)。
gzip_buffers
:
- 默认值:
gzip_buffers44k/8k
- 设置系统获取几个单位的缓存用于存储
gzip
的压缩结果数据流。 例如 4 4k 代表以4k为单位,按照原始数据大小以4k为单位的4倍申请内存。 4 8k 代表以8k为单位,按照原始数据大小以8k为单位的4倍申请内存。 - 如果没有设置,默认值是申请跟原始数据相同大小的内存空间去存储
gzip
压缩结果。
gziphttpversion:
- 默认值:
gzip_http_version1.1
(就是说对HTTP/1.1
协议的请求才会进行gzip
压缩) - 注:99.99%的浏览器基本上都支持
gzip
解压了,所以可以不用设这个值,保持系统默认即可。
保存配置后,重新启动 Nginx
:
$ sudo service nginx restart

开启gzip前

开启gzip后
4. 如何验证 gzip
?
可以看 Network
,但这里我更推荐用 curl
:
通过使用 curl
测试每个资源的请求响应,并检查 Content-Encoding
:

显示 Content-Encoding:gzip
,即为配置成功。
5. 双端Gzip区别详解
不同之处在于:
Webpack
压缩会在构建运行期间一次压缩文件,然后将这些压缩版本保存到磁盘。nginx
在请求时压缩文件时,某些包可能内置了缓存,因此性能损失只发生一次(或不经常),但通常不同之处在于,这将在响应HTTP
请求时发生。- 对于实时压缩,让上游代理(例如
Nginx
)处理gzip
和缓存通常更高效,因为它们是专门为此而构建的,并且不会遭受服务端程序运行时的开销(许多都是用C语言编写的) 。 - 使用
Webpack
的好处是,Nginx
每次请求服务端都要压缩很久才回返回信息回来,不仅服务器开销会增大很多,请求方也会等的不耐烦。我们在Webpack
打包时就直接生成高压缩等级的文件,作为静态资源放在服务器上,这时将Nginx
作为二重保障就会高效很多。 - 注:具体是在请求时实时压缩,或在构建时去生成压缩文件,就要看项目业务情况。
免责声明
不是打算教 Webpack
或 Nginx
,只是觉得好玩就简单写了一下。