为提高网页加载速度,启用 gzip 缩减资源的大小是非常常见的手段。现代浏览器均支持 gzip 压缩,并会为HTTP请求自动协商此类压缩。
本文将对 gzip 的实践和原理做一个简单的总结。
web服务器在接收到浏览器的请求之后,会检查浏览器可以接受哪些压缩方法,详情可见下图。
浏览器在请求头中会带上 Accept-Encoding 这个参数来说明自己支持哪些内容编码方式。
而服务端返回的 Response Headers 中则存在一个 Content-Encoding ,用来说明数据的压缩方法。
几乎所有的浏览器都已经支持了 gzip ,并且有请求头的验证,所以基本不需要担心兼容相关的问题。
压缩前后的体积前后差异,可以在控制台中看到。可以说,对于js、css文件的压缩率还是比较可观的。
经过这种方式的配置,在服务端响应请求的时候会对文件进行压缩,之后返回压缩过后的内容。不过压缩这一过程多多少少会占用一些服务端的性能,具体压缩的程度,也就是 gzip_comp_level 设置的值也会影响到占用性能的多少,接下来我们来看一些网上搜集到的数据,了解不同值的设置对文件大小和CPU占用的影响。
可以看到,压缩级别从0到1时,文件大小明显减小,CPU消耗略微上涨。而在之后文件减小的速率明显放缓,在达到了5之后继续增加压缩级别,文件的体积也几乎没有缩小,但CPU消耗却有较为明显的上涨。
根据结论可以看出,如果是在服务端使用 gzip 压缩的话,考虑到性能和压缩率的取舍,将压缩级别设置为一个较低的值,比如2之类的,是比较合理的。
我们也可以选择在打包构建项目的时候就对文件进行gzip压缩
这边以打包一个 webpack 的前端项目为例
运行构建命令后可以看到,在生成 .js 和 .css 的同时还生成了对应的 .gz 文件。
在这种方式的压缩中,我们完全可以把压缩等级设置为一个比较高的值(默认),毕竟只是略微影响打包的时间,却能获取一个更小的体积的包,还是比较值得的。
以 nginx 为例,静态压缩需要使用 http_gzip_static_module 这个模块,这个模块不是默认的,应使用 --with-http_gzip_static_module 的配置参数启用它
之后再配置中添加
这样便可开启静态压缩。
需要注意以下几点:
由于我们团队的前端项目越来越庞大,加之Vue的SPA首屏加载特性,导致系统第一次加载速度越来越缓慢,可能达到几十秒的程度,所以为了优化用户性能体验,我们选择了开启Gzip进行文件压缩,确实达到了显著的效果。
Gzip原本用户UNIX系统的文件压缩,后来逐渐成为Internet最主流的数据压缩格式。
当用户访问我们的web站点时,服务器就将我们的网页文件进行压缩,将压缩后的文件传输到客户端,对于纯文本文件我们可以至少压缩到原大小的40%,这样大大提高了传输效率,页面便可更快的加载出来。
由于目前我们项目是使用ngxin来部署前端的,nginx自带 HttpGzip模块 , 所以我们直接对 nginx.conf 文件的http配置项进行配置即可。但相对的由于nginx自身处理请求然后压缩返回,会消耗对应的服务器内存。
测试效果
我们应尽可能减少对服务端内存的使用,毕竟服务端的资源是十分宝贵的,这里我们仍然使用nginx进行前端部署,我们在客户端替nginx处理压缩文件这一步 *** 作,nginx便可直接使用我们压缩好的文件,下面是一个基于vue-cli配置的前端项目。
这里最好安装低版本,防止报错。
这里可以根据大家不同的配置,总之就是将webpack插件进行注册。
成功运行后,便可以在打包文件中看到.gz结尾的文件了,将打包后的文件上传到指定的nginx文件夹下。
这里需要nginx对应的插件 http_gzip_static_module ,之前我是通过yum安装的nginx,这里似乎不可以,需要手动安装。这里目录可以根据大家个人情况而定。
安装nginx
修改nginx.conf
启动nginx服务
这里我们虽然服务端js文件夹里只有.gz格式的文件(其他的文件已删除),但客户端却成功读取了。
无论是服务端与客户端进行gzip的压缩,我们都大大缩小了文件体积,给用户带来了更好的体验。
服务端处理gzip优点是只需配置一下即可,无需复杂 *** 作,但缺点是会消耗服务器内存。
客户端处理gzip优点是无需服务器进行文件压缩,减少服务器内存消耗,但配置起来相比服务端gzip会稍加繁琐。
Nginx中文文档
什么是GZIP,有什么优势,如何开启GZIP?
vue-cli4 开发项目中开启gzip压缩,优化打包体积,提升加载速度
Nginx gzip static静态压缩
配置nginx直接使用webpack生成的gz压缩文件,而不用nginx自己压缩
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)