为什么要开启双端GZIP压缩？
因为压缩之后的文件或者js体积小，传输速度快，占用带宽更小，可以系统提高吞吐量（并发访问量）怎样判断是否开启双端压缩了，或者看支持哪种压缩？
一般情况，会查看前端请求，如果前端支持压缩会显示Accept-Encoding:gzip，用户说明接受哪些压缩方法后端会给前端请求返回响应Content-Encoding: gzip，deflate表明后端服务支持哪些压缩常见的压缩方法
webpack前端 gzip压缩
nginx gzip设置
tomcat gzip设置
Apache开启开启mod_deflate模块压缩
IIS开启GZIP
webpack方式需要安装插件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 }) ) nginx配置 打开 /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; ... }tomcat: 原配置：
<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" useBodyEncodingForURI="true" URIEncoding="UTF-8" />修改后：
<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" useBodyEncodingForURI="true" URIEncoding="UTF-8" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla,traviata" compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript,text/css,text/plain" />compression=“on” 打开压缩功能 compressionMinSize=“50” 启用压缩的输出内容大小，默认为2KB noCompressionUserAgents=“gozilla, traviata” 对于以下的浏览器，不启用压缩 compressableMimeType=“text/html,text/xml,text/javascript,text/css,text/plain” 哪些资源类型需要压缩 重启 tomcat 即可
不同之处在于：
Webpack压缩会在构建运行期间一次压缩文件，然后将这些压缩版本保存到磁盘。 nginx在请求时压缩文件时，某些包可能内置了缓存,因此性能损失只发生一次(或不经常),但通常不同之处在于,这将在响应 HTTP请求时发生。 对于实时压缩,让上游代理(例如 Nginx)处理 gzip和缓存通常更高效，因为它们是专门为此而构建的,并且不会遭受服务端程序运行时的开销(许多都是用C语言编写的) 。 使用 Webpack的好处是， Nginx每次请求服务端都要压缩很久才回返回信息回来，不仅服务器开销会增大很多，请求方也会等的不耐烦。我们在 Webpack打包时就直接生成高压缩等级的文件，作为静态资源放在服务器上，这时将 Nginx作为二重保障就会高效很多。 注：具体是在请求时实时压缩，或在构建时去生成压缩文件，就要看项目业务情况。 nginx gzip有个坑，默认是对http1.1协议生效，如果nginx前面也是nginx，过来的请求是http1.0，导致gzip不生效，png的图片不必进行压缩。参考：https://juejin.im/post/5cb7ee0e51882532fe3440ea https://juejin.im/post/5af003286fb9a07aac24611b
