电子商务系统前端性能优化的研究与实现 陈韵晴 - 图文 联系客服

发布时间 : 星期二 文章电子商务系统前端性能优化的研究与实现 陈韵晴 - 图文更新完毕开始阅读

3.3 压缩组件

3.2.1 原理

压缩技术利用减少响应传输的组件的数据量,从而减少HTTP响应包的传输时间,最终减少响应时间。

随着网页要求越来越高,页面组件的个数和数据量增大,当浏览器向服务器请求资源时,这么庞大的数据量将使得用户等待时间变得很长。虽然前端人员无法控制网络带宽等因素,但是可以通过减少响应传输的组件的数据量来缩短响应时间。HTTP请求包数据量较小,所以可以不采取压缩,主要是考虑HTTP响应包,当请求的资源数据量比较多时,其传输的时间自然会变得很长。所以,为了减小资源数据量,缩短服务器发送的数据在网络中传输所用的时间,可以通过压缩HTTP响应包的方式来解决。采用压缩技术需要的代价相对而言很小,只是使得服务器的CPU被占用多一些,大概多1%或更少。因此,压缩组件是减少资源数据量最简单而又影响最大的方式。

3.2.2 Gzip压缩

服务器和浏览器都遵循压缩技术的协议,当前的主流浏览器比如IE、Chrome、FireFox等,服务器比如IIS11、Apache、Nginx12等都是可以使用压缩技术的。在这些压缩技术中,Gzip压缩13在互联网上最为常用,也可以采用deflate压缩14,不过现在deflate压缩已经有些过时了,支持使用这种方式的占点也不多,而且Gzip较deflate的压缩效果更佳。Gzip压缩可以使资源压缩为原来的40%以下,比deflate还要少压缩大概4%-6%的内容15。压缩虽然使得服务器要占用更多的CPU资源来进行压缩,浏览器也得通过解压步骤来得到原本的数据,但是压缩之后得到的效益一般是超过其付出的代价的。根据经验,通常对1KB到2KB的文件进行压缩。

因此,我们有必要对请求的资源比如HTML文件、CSS文件、JS文件,以及服务器返回的响应信息和文本文件进行Gzip压缩,而像图片、视频等资源则没有那么迫切的压缩需求,它们本来就已经是压缩得到的,再压缩不仅不能节省太大的空间,还会无意义地提高服务器CPU的占用率。

压缩的途径有很多种,最简单的就是在Web服务器开启Gzip压缩,通过查看服务器相关的配置文档来开启了这个功能后,代码文件有更小的体积,尤其是文本文件。然后浏览器在HTTP请求头信息中的“Accept-Encoding”一项内容中,说明自身可以接受哪一种压缩方式。当然,压缩格式不限于Gzip压缩这一种,比如当客户端可以接受的压缩格式是Gzip、deflate、sdch时,那么就可以在请求头中的Accept-Encoding一项写“gzip,deflate,sdch”,这样服务器接收到包含这样信息的HTTP请求后,就知道选择其中一种压缩格式的文件来返回响应了,这样响应头里就会通过“content-Encoding:gzip”标明返回的压缩格式,让浏览器知道怎么去处理这个响应。

3.2.3 代理服务器缓存

代理缓存16是指代理服务器下载某些被经常被请求的资源的缓存,以此来减少Web服务器总是处理相同请求的情况。对于需要缓存的资源,代理服务器第一次接受用户请求时需要先转发到Web服务器,收到响应后将之返回给用户并保存该资源,并服务于后续其他用户的相同请求,这样可以提高响应速度。

这种机制需要注意避免存在的一些问题,例如代理服务器接受的一个请求是由一个支持Gzip的客户端发送的,这时候代理服务器的缓存中就存在该资源的Gzip压缩版本,而接下来再接受的请求中有不支持这个压缩方式的浏览器,那么代理服务器会将之前的压缩版本提供给这些浏览器,这样就使得浏览器接收到了不该收到的响应。要注意避免这种情况的发生,应该在Web服务器对代理服务器的响应头信息中增加一个Vary头信息,告诉代理服务器按照这个头的信息来缓存不同的版本。比如压缩的类型是在“Accept-Encoding”头信息的内容中说明的,那么就应该在Web服务器返回响应的Vary一项中标明“Accept-Encoding”这个信息,使得代理缓存服务器知道为支持不同压缩方式的用户请求缓存一个资源,即为多个压缩类型各缓存一个版本。

3.4 页面元素的优化

3.2.1 原理

每次加载一个组件都得向服务器发送一个HTTP请求,现在HTTP1.1规范下较高级的浏览器每次从每个主机名可以并行下载最多6个组件,也就是说一次最多发送6个HTTP请求,当网页从一个域请求比较多的组件时,很多组件会被阻滞,大大延长了响应时间。

HTML还有图片、CSS、脚本等组件都是用于加载显示一个页面的,对于同一类型的文件,一般而言浏览器会按照他们在HTML中出现的先后顺序进行HTTP请求的发送,而不同类型的文件则有不同的优先顺序。下面通过4个例子来说明这种优先顺序,四个HTML例子中都包含同样的3个图片、4个CSS、4个JS。

图3-6 eles_cssdown_jsup.html

eles_cssdown_jsup.html把JS放在顶部,图片在中间,CSS放在页面底部,结果显示虽然先遇到顶部的JS和中间的图片,但是实际上却先为4个CSS和2个JS(浏览器并行连接数为6)发送HTTP请求和后续处理,再处理剩下的2个JS,接着才是图片。

图3-7 eles_cssup_jsdown.html

eles_cssup_jsdown.html把CSS放在页面顶部,图片在中间,JS放在底部,结果显示仍是先为4个CSS和2个JS发送HTTP请求并下载,再处理剩下的2个JS和图片。