gzip压缩实践

html-css021

gzip压缩实践,第1张

为提高网页加载速度，启用 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 的配置参数启用它

之后再配置中添加

这样便可开启静态压缩。

需要注意以下几点：

直接给出结论： 1、css并不会阻塞DOM树的解析 2、css加载会阻塞DOM树渲染 3、css加载会阻塞后面js语句的执行 为了避免过长的白屏时间，我们应该尽可能的提高css加载速度，以下有几种优化方法: 1、使用CDN(因为CDN会根据你的网络状况，替你挑选最近的一个具有缓存内容的节点为你提供资源，因此可以减少加载时间) 2、对css进行压缩(可以用很多打包工具，比如webpack,gulp等，也可以通过开启gzip压缩) 3、合理的使用缓存(设置cache-control,expires,以及E-tag都是不错的，不过要注意一个问题，就是文件更新后，你要避免缓存而带来的影响。其中一个解决防范是在文件名字后面加一个版本号) 4、减少http请求数，将多个css文件合并，或者是干脆直接写成内联样式(内联样式的一个缺点就是不能缓存) 关于DOMContentLoaded： 对于浏览器来说，页面加载主要有两个事件，一个是DOMContentLoaded，另一个是onLoad。而onLoad没什么好说的，就是等待页面的所有资源都加载完成才会触发，这些资源包括css、js、图片视频等。 1、如果页面中同时存在css和js，并且存在js在css后面，则DOMContentLoaded事件会在css加载完后才执行。 2、其他情况下，DOMContentLoaded都不会等待css加载，并且DOMContentLoaded事件也不会等待图片、视频等其他资源加载。 参考自：https://juejin.cn/post/6844903667733118983