文章目录
一、什么是web的性能优化
web的性能指标有很多，大致可以分为三类：
- 首次访问速度。首次访问速度主要指首页的加载速度，这个在移动端显得尤为可贵，对于大厂的h5 app，这一块的优化一直都是头疼的问题，例如淘宝首页，手百首页等等，让用户多看几百毫秒的白屏，都会让pm逼死一帮程序猿。
- 持续访问速度。持续访问速度更多指对于CPU，GPU，内存等资源的使用，使用过程中的是否有卡顿，是否保持流畅等等。
- web的健壮性。健壮是指，对于对于并发，大量请求和访问，web安全等等极端情况下web的可用性。
这次我们要讲的是主要是第一点，首次加载时，web性能的优化，这也是一版前端面试会的常考点。之后的web 性能优化均指的是第一点。
二、web性能优化的目的
- 优化用户体验，提升用户留存率。有人研究过：2秒之内，95%以上的实验者保持良好的注意力，3秒之后注意力开始分散；当等待时间超过5秒，70%的实验者能保持良好的注意力；当等待时间超过9秒，仅剩下20%能保持良好的注意力，对于不同首屏加载等待时间对于用户的留存，每个大厂不尽相同，但是大家都不知觉的精确到毫秒级，重要性可想而知。
- 提升web的SEO排名。在17年10月，百度就推出了对于首评加载时长超过3秒的web，降低其权重的“闪电算法”
三、web性能优化的原理
web性能的优化的原理，不得不提到浏览器在加载web首页时做的工作了，我们搞清楚了他的工作步骤，才能知道优化的点在哪里。下图是浏览器渲染的几个步骤：
上图中有几点需要我们注意一下：
3. DOM和CSS OM是有先后开始，但是在过程中是可以(注意是可以，不是一定，也不是不行)同步进行的
4. DOM和CSSOM 都和js的解析是互斥的，这个很好理解，js可以修改dom节点或者css样式，所以js会阻塞其他两个的进程，直至js执行完毕
那么他的执行顺序大致可以这么看
下面我们结合chorme的新增功能performance(控制台>performance)来对于每一个步骤的工作进行分析：
3.1 加载文档
常见的浏览器文档类型有，HTML、XHTML、SVG，XML，在用户打开浏览器的时候，首先要做的是解析域名和dns，找到对应的IP，然后通过校验之后，像服务器发起请求，服务器相应的内容就是要加载的文档。
3.2 生成dom树
这个过程主要是把文档解析成DOCUMENT OBJECT，例如html的<html> </html> <body></body>，这个结构的解析，浏览器内置的都可以直接解析这些文档，不用依赖任何其他的文件，所以这个过程会很快，最终生成表示能够表示整个文档和每个节点的类型，数据和节点关系的树形结构，简称dom树。
需要注意一点：这里是全部的node节点，即使<div style=“display:none”> 该节点会依然在dom树中存在
3.3 加载css 和js
这个之所以会算作一个过程，是因为随着web的发展，很多web越来越大，功能也越来越复杂，引入的css和js也越来越多，在整个页面中也慢慢的占据一定的位置。
5. 加载css包括 html中的css代码块，内联样式，和需要下载的外部样式
6. js 主要指下载外部引入的js文件
3.4 生成CSS OM
CSSOM是将对应的样式绑定到对应的节点上，为什么会有树的概念，个人理解，cssom tree有点像树上开的花，来表示节点的属性，而且树的根节点和子节点，也很好的表示了css的优先级，比如父布局的一些样式对于子样式的影响，但是在css om tree中并不是最终的样式。
- 是用户代理样式的重新计算
- 不包含所有的dom节点
3.5 rending tree
这个过程是DOM和CSS OM合并的过程，这个过程中主要做：
- 去除dom树中和页面渲染无关的节点，比如head 、mate等
- 计算和合并cssOm，并应用到dom树上
- 从dom树上去除display：none的节点，visiable：false的不会移除
这样就生成了rend tree。
3.6 layout（flow 、reflow）
这个过程成为layout或者flow，布局，主要是来计算每个node的尺寸，位置和颜色等信息，为了下一步的绘制作准备，因为这个过程并不是只执行一次，比如js解析的时候，调整某一个node节点的尺寸或者位置，就会导致重新计算，所以也可以成为reflow。
影响重新布局的原因如下：
- 节点的增改
- 节点样式的修改（不是全部，比如背景色就不会导致重新布局）
- 用户发起的事件，鼠标事件等等
3.7 paint（repaint）
绘制，原因和上方相同，都不止一次，会应为reflow，导致repaint。这里需要注意一点，paint的绘制是多线程分块进行的，可以在下图的三 看到，多个绘制并发进行。
3.8 composite （合并）
从3.7可以看到，分层绘制，带来了并行，提升了效率，但是最后需要将绘制的结果合并成一个页面，呈现给用户。
讲到这里渲染的原理基本差不多了，接下来，才进入正题，我想，你如果看到这里，应该也能想到很多可以优化的点了。
四、性能优化
我们的性能也是会结果上面的步骤，进行阐述，对应这个阶段的优化点哦。
4.1 html的语义化编程
语义化标签是浏览器内置就能解析识别的标签，最终的实现也会dom的结构简洁话，所以就会减少时间消耗哦
4.2 资源的加速
- 静态资源的cnd加速
- 图片资源的压缩
- 合并资源请求，虽然会增加单个请求的时间，但是发起请求，关闭请求的操作，很耗费资源。
- css资源的分片加载，最常见的就是
<link rel="stylesheet" type="text/css" media="print">
media属性可以接受一个或多个媒体值表，浏览器会根据当前的媒体值，来加载对应的样式表，这样就要比把所有的样式放在同一个样式文件中要来的好
- js的异步加载
js文件的异步加载，一个页面的初始化中，因为很多时候外部的js文件相对大小还是不小的，如果这些文件不着急执行，可以添加这个属性，表示异步加载，不会阻塞其他的操作
<script type="text/javascript" src="" async>
async标签告诉浏览器，这个文件不着急加载，浏览器会在合适的时间来加载对应的文件
4.3 js的优化
- js代码尽量不要写在head中
- defer属性
<script type="text/javascript" src="" defer>
这个属性告诉浏览器，这个文件不着急执行，和首页的渲染关系不大，可以等到页面加载和渲染完成之后再执行，比如对于node绑定事件等等
4.4 CSSOM 优化
- 内部样式尽量写在head中（或者说成写在文件尽可能的上方）因为是文档是子上而下的解析，如果写在下方，或者中间，遇到js会阻塞dom和cssom操作，所以避免这个情况，应该规范在head中
- 尽量少使用内联样式，原因如上
- 尽可能的不使用 @import 属性，import属性会在页面加载完成之后，或者使用到该css代码块的时候采取加载对应的文件，等效于把css写到的文档的底部，所以应该避免这种情况。
- less，secc的嵌套写法，这个写起来很爽，嗯，就是这样
4.5 dom操作节流
- 这个最常见，也是面试题中问的最多的,下面的demo比较极端
for (var i in 10) {
arr[i].width = document.getElementById("a").offsetTop
}
//这样的话会导致页面每次都要去从新的绘制，拿到offsetTop,下面就会好很多
let top = document.getElementById("a").offsetTop
for (var i in 10) {
arr[i].width = top
}
2.不得不提到，前端框架，vue，虚拟节点，把dom操作缓存起来，定期的统一触发dom刷新，这个优势体现在，比如修改div的宽一次，高一次，用虚拟节点的形式，最终只会渲染重绘一次
4.6 加载渲染分流
可以参考淘宝首页，可以看到task分批加载，如果网速设置慢一点可以看到，从上而下的分段加载，让用户不至于看到全部白屏，能看到。
4.7 避免repaint和reflow
对于transform和opacity，会在单独的层级进行绘制，所以他们的改动不会触发回流，因此在一些可以使用
.element {
will-change: transform;
}
来通知浏览器提升这个node的层级，在之后更新是会单独层绘制
讲到这，基本常用的介绍完啦
