时间都去哪了-移动Web首屏优化实践

今天药忘吃喽~ 2022-07-13 09:42 244阅读 0赞

## 时间都去哪了-移动Web首屏优化实践 ##

![0iEgfel.png][]

### 首屏时间 ###

可用性的前提，后面用户是否使用你app很重要的因素之一；

![2tDhpfK.png][]

我们PC上访问其实现在的带宽已经很好了，百兆光宽带，但是在移动端就不一样了，很多用户还是使用的流量，GPRS。所以，对于首屏时间的加载，压力还是蛮大的；

### 我们手机在出发一个操作之后，发生了什么？ ###

下面是在返回数据前发生的动作，但是作为前端，我们好像动不了这些东西，不可能叫运营商去帮你定制一套系统；

![XqR3FKn.png][]

这个才是我们真正要去做的东西—渲染（webkit）

![nh48ML3.png][]

给你两个优化的方面，优化网路与优化渲染（高性能js，但是很多时候我们技能用不到），其实优化网络，我们可以提升几秒，而优化渲染，我们大部分是是毫秒级的，所以网络优化才是重点；但有时候我们往往动不了；

网络层的优化

![uKsCGS6.png][]

上述这些步骤，能否在1秒内完成，很难，但是当我们合理利用缓存等一些技术时，还是可以的；

上述有一个概念RTT，用人话讲就是一次请求往返的时间

![4PQzFnT.png][]

下面是一些常见网络的RTT时间

![zjyvr0T.png][]

我们还可以通过一些常用的工具去测试网络的耗时；

![pF92TbS.png][]

可以查看每个js的解析时间，http响应时间，tcp建立时间

### 那我们要怎么做呢？ ###

我们可以从以下几个方面着手，这些都是一些经典的使用场景，但是我们知道要这么做，但更应该知道为什么要这么做；

![xvlAYeJ.png][]

首先，第一个减少请求数？为什么？

请求多了，并不是说会对后台造成多大的压力，这当然是一方面，从RTT上来说，每一个请求都会消耗一个RTT时间，那么越多的请求消耗的RTT时间就越多；

比如请求一个5K的css和一个200K的图片，除了请求大小不一样之外，深入到协议里面，并不是请求的数据一次性的返回一个包给你，因为为了防止网络拥塞，会有一个窗口来限制你的包的大小；所以建议初试化的包控制在14k以内，只是tcp窗口的大小。

再次，利用缓存；

然后是合理安排请求顺序，哪些请求是必须先加载的，哪些可以稍后加载。那怎么做呢？

**1. DNS预解析**

![JFzXhKE.png][]

**2.域名收敛**

既然DNS解析比较耗时，每个连接都要建立链路，那么我们就可以通过减少ajax到后台的域名地址，通过反向代理去做。

![Bnbby98.png][]

**3. 链路复用**

因为每一次链接数都要建立3次TCP握手，通过keep-alive，可以保证建立的连接不会被关闭， 下次请求可以直接发送数据，这样可以减少将近200ms的时间，当然会增加一部分Server的内存消耗，要预先扩容；http2.0已经支持了这些特性；

![Njz2MFq.png][]

**4. 资源内联**

在首屏里，一些资源都是分散开发的，在一些简单的页面中，有些内容可以内联进去，不然像一些css页面要等到html页面解析完成后，再去解析外联的css； 可以通过打包工具在发布的时候就能完成；

![820bMhd.png][]

**5.组件化开发**

![GktlBLa.png][]

首先一点是按需加载，就是首屏显示的东西，哪些要加载，哪些无需加载，可以区分开来，而且可以异步方式来加载，如上图是一块一块的加载出来，而不是一步全部加载出来；

然后一个是一部渲染，这里举个例子；如下的tab选项卡

![0Tz3hh4.png][]

我们通常是这么做的，我们可以先加载一些公用的东西，然后通过路由，去加载首屏上可以看到选项卡的资源，哪些有用户交互之后的东西，可以稍后在加载；

![ZG3zM4q.png][]

但是这样会有一个问题，有时候我们的js处理的比较快，但是css文件处理的比较快，这样就会使的页面比较混乱，所以可以通过异步打包工具，将css和js打包在一起

![dG4vEV5.png][]

**6. 服务端渲染**

![b3fWxdZ.png][]

一个前后端分离的项目，通过ajax请求数据，这样一个页面的渲染路径会拉的很长，页面先渲染html，然后在渲染js，js才发送ajax请求，等到数据回来再进行渲染，所以不管怎么样都至少要3个RTT请求时间；这种模式，在网络环境比较差的情况下，是很难接受的，

所以我们又回归到PHP时代；通过服务器端渲染，就可以控制用户，哪些东西是要打包的。可以一次性知道用户需要哪些数据；加上现在的NodeJs环境以及React，这就使得一些东西既可以在前端的浏览器进行渲染，也可以在服务器中进行字符串拼接，一起吐出来；

比如在无限长的滚动列表中，对图片进行懒加载，首先不给图片赋值src属性，通过插入dom计算可视区，在可视区内则赋值src，在可视区之外，交给scroll去处理，将要进入可视区时才赋值；

![1Xky4HO.png][]

**7.利用缓存**

![2aC7OSa.png][]

资源长缓存：不是通过304去判断缓存，而是通过max-age来做的，通过md5命名文件，然后通过自动化构建工具去实现；

主要聊一下数据层缓存与数据复用；

从客户端的启发；客户端会将上次缓存的数据重新渲染一遍；所以数据缓存的设计可以设计为

![Vx1s7g5.png][]

可以在ajax请求的数据没有回来之前，用一些配置的假数据，先把坑站好，然后等待线上的数据回来后，在把坑填好，这样减少了白屏的时间。这样给用户感觉比较快，但不是真的快，交互性能确实变好了；

![lxU9JMQ.png][]

在有些时候，并不是所有的数据都是加载进来的，像贴吧和知乎之类的，展示的一些storage里的数据，都是带有省略号的缓存数据，等用户真的点开之后才去加载该帖子的全部数据。每次请求的数据又重新将原来的缓存覆盖；

![6khi1LA.png][]

**8.离线包**

![cDPpwHM.png][]

其实对于一些并发量比较大，向过年时候的抢红包业务，并发量是几个亿。这样，对于一些经常使用的用户，可以几天前就将离线包推送过去，进行下载，通过二进制比较，进行动态增量更新，而不用每次都下载，这么大的并发量，同时下载，带宽肯定爆，服务器肯定爆。

**9.是在优化不了怎么办？**

转菊花！！！

![qvWon1O.png][]

[0iEgfel.png]: http://i.imgur.com/0iEgfel.png
[2tDhpfK.png]: http://i.imgur.com/2tDhpfK.png
[XqR3FKn.png]: http://i.imgur.com/XqR3FKn.png
[nh48ML3.png]: http://i.imgur.com/nh48ML3.png
[uKsCGS6.png]: http://i.imgur.com/uKsCGS6.png
[4PQzFnT.png]: http://i.imgur.com/4PQzFnT.png
[zjyvr0T.png]: http://i.imgur.com/zjyvr0T.png
[pF92TbS.png]: http://i.imgur.com/pF92TbS.png
[xvlAYeJ.png]: http://i.imgur.com/xvlAYeJ.png
[JFzXhKE.png]: http://i.imgur.com/JFzXhKE.png
[Bnbby98.png]: http://i.imgur.com/Bnbby98.png
[Njz2MFq.png]: http://i.imgur.com/Njz2MFq.png
[820bMhd.png]: http://i.imgur.com/820bMhd.png
[GktlBLa.png]: http://i.imgur.com/GktlBLa.png
[0Tz3hh4.png]: http://i.imgur.com/0Tz3hh4.png
[ZG3zM4q.png]: http://i.imgur.com/ZG3zM4q.png
[dG4vEV5.png]: http://i.imgur.com/dG4vEV5.png
[b3fWxdZ.png]: http://i.imgur.com/b3fWxdZ.png
[1Xky4HO.png]: http://i.imgur.com/1Xky4HO.png
[2aC7OSa.png]: http://i.imgur.com/2aC7OSa.png
[Vx1s7g5.png]: http://i.imgur.com/Vx1s7g5.png
[lxU9JMQ.png]: http://i.imgur.com/lxU9JMQ.png
[6khi1LA.png]: http://i.imgur.com/6khi1LA.png
[cDPpwHM.png]: http://i.imgur.com/cDPpwHM.png
[qvWon1O.png]: http://i.imgur.com/qvWon1O.png