http是性能优化最见效的点

前言

虽然说没有机会参与大型的项目开发,但是自己也捣鼓过几个小项目,作为一个前端开发者,了解和掌握一些后端服务是非常有必要的,记得当初自己学ajax的时候很苦恼,因为压根就找不到合适的数据去请求,要不就是跨域,要不就是访问本地静态文件,所以索性就自己学了node作为后端提供数据接口API,当整个流程走通后,才能真正地理解http性能优化到底要怎么做,怎么样的才是最佳实践,总结以下我所用到的一些优化方案。

优化

主要从http的几个维度来分析:

  1. http请求次数
  2. http请求频率
  3. http请求的数据大小

带着这个几个维度,我们来开始分析http优化。

减少http的请求数

我们每次发送一个请求,都会经历一个相同的过程: 发送请求、经过DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据。无论我们请求的数据大或小,都是要经历一个这样相同的过程。

假如我们设置这个过程的时间固定为1s,请求数据每1M花费1s,我们要从服务器获取10M的json内容,我们有两种方案:

  1. 分10次请求每次获取1M内容,时间是20s。
  2. 一次获取10M内容,时间是11s。

通过这个简单的分析,就能发现这是一个非常有效的http优化方案,当一个页面有非常多数据的时候,利用这种“合璧”方案就会得到很大的性能提升,那么我们可以从哪些方面着手呢?

资源合并与压缩

现在前端模块化开发给我们带来很大的便利,当然将很多模块拆分开来就会形成很多的文件资源,所以一般我们都会用webpack这样的打包工具来将js css的资源合并压缩,这样用户只需要发送一个请求便能获取到页面需要的执行代码。

CSS Sprites

css雪碧图,这是个非常非常古老的技术,我们利用了background的裁剪,将一张图片拆分成很多的图片供网页使用,我们以京东的官网来看,一般雪碧图用来存放一些小logo,因为网页上要用用到很多,单个logo文件又非常小,索性将它集中在一起,通过css一些黑魔法来实现。

image

用http缓存避免重复资源请求

http有个状态码是304,这表示数据没有发生变化,无需再次请求,作为后端可以利用这一点优化前端的性能,既能减少用户等待时间,服务器也能节约资源,在我的项目中,用koa或者express做public静态文件处理的时候,会默认实现缓存。

用前端状态管理工具避免重复资源请求

原本这是没必要提出来的,但是我的项目中一般都会用redux来存储一些网络数据,比如之前做的博客,当用户第一次进入列表页时,请求到的列表数据存在redux的store中,当用户从其他的页面切换过来的时候,不会再次重复发送请求,但是用状态管理工具来存储数据一定要注意,数据量不能大,像整片博客内容这种大数据最好就不要存在store中,避免内存消耗过大,影响性能。

降低http请求频率

由于浏览器进行并发请求的请求数是有上限的,因此请求数多了以后,浏览器需要分批进行请求,因此会增加用户的等待时间,会给 用户造成站点速度慢这样一个印象,即使可能用户能看到的第一屏的资源都已经请求完了,但是浏览器的进度条会一直存在,这就非常影响用户体验了。

Lazy Load Images

当页面上有大量图片的时候,一般为了用户体验都是先加载用户“目前所看到的图片”,像一些购物商城,或者摄影网站,用的非常普遍。

Lazy Load Javascript

首屏渲染往往给用户留下深刻的影响,当输入url按下回车开始,如果超过3s还是空白,那么给用户留下很坏的印象,降低二次访问的欲望。现在前端框架对于这点提出了有效的解决方案,我们从两个方面来看:

  1. 当项目打包时,在webpack设置公共库,比如一个react项目,他的react、react-router、redux这些库都是很久不变的,没必要每次项目更新都打包一样的东西在bundle.js中,设置公共库后,打包出来的vendor.js就是你所设置好的公共库,用户下次在再次访问就只要加载哪些有所改变的js代码。

  2. 我们再来分析,进入一个网页的首屏往往不会操作过多的东西,这样的话,我们就可以在不同的路由下加载不同的包,这样就能减少首屏加载脚本的时间。

减小http请求数据大小

http请求时间和返回数据的大小是成正比的,这个道理很简单,我们真正开发的时候一定要和后端的小伙伴商量好自己需要哪些东西,不需要的东西一律去除。

后端只返回需要的数据

项目开发前和后端小伙伴商量好,哪些内容是必要的,或者哪些内容是暂时还不需要的,尽量不要求一次性请求过多的数据,之前开发的时候,没有注意到这点,获取了非常多不必要的数据,优化后,请求速度有了质的飞跃

开启gzip压缩

这是一个非常有效的方法,效果也非常明显,一般能压缩三分之二的内容,但是在高并发的的场景下,服务器可能无法承受大量的压缩任务。下图绿色边框是表示在服务器开启gzip压缩后的大小,边框下面是表示资源本身的大小。

image

总结

以上便是我开发过程中对于http的性能优化的,虽然说效果很明显,但是距离性能极致话还是远远不够的,非常期待实习的时候能加入一个大团队,在优化上有更深入的探究。

hava a nice day :)