在运行的时候即使是在电脑浏览器上也会隐约觉得动画的运行并不流畅，更不要提在移动端达到60fps的流畅效果了。这是因为top和left的改变会触发浏览器的reflow和repaint，整个动画过程都在不断触发浏览器的重新渲染，这个过程是很影响性能的。
为了解决这个问题，我们使用transform中的translate()来替换top和left
这个时候我们就会发现整个动画效果流畅了很多，在动画移动的过程中也没有发生repaint和reflow。那么为什么transform没有出发repaint呢？原因就是transform动画由GPU控制，支持硬件加速，并不需要软件方面的渲染。
浏览器收到页面文档后，会将文档中的标记语言解析为DOM树，DOM和CSS结合后形成浏览器构建页面的渲染树，渲染树中包含了大量的渲染元素，每一个渲染元素会被分到一个图层中，每个又会被加载到GPU形成渲染纹理，而图层在GPU中transform是不会触发repaint的，这一点非常类似3D绘图功能，最终这些使用transform的图层都会使用独立的合成器进程进行处理，移动时的变化也是独立的，不会影响到页面的其他元素，造成重排重绘是因为影响到页面的其他图层元素导致的，可以理解为其他元素都是在一个图层空间，所以一个图层移动其他的也会收到影响，而transform创建了一个新的复合图层，它会被GPU独立执行transform操作，跟其他图层互不影响，所以不会引起重排重绘。
此时，你也许会问浏览器什么时候会创建一个独立的复合图层呢？事实上一般是在以下几种情况下：
因为GPU进程会为其开启一个新的复合图层，不会影响默认复合图层（就是普通文档流），所以并不会影响周边的 DOM 结构，而属性的改变也会交给 GPU 处理，不会进行重排。使 GPU 进程开启一个新的复合图层的方式还有 3D 动画，过渡动画，以及 opacity 属性，还有一些标签，这些都可以创建新的复合图层。这些方式叫做硬件加速方式。你可以想象成新的复合图层和默认复合图层是两幅画，相互独立，不会彼此影响。降低重排的方式：要么减少次数，要么降低影响范围，创建新的复合图层就是第二种优化方式。绝对布局虽然脱离了文档流，但不会创建新的复合图层，因此当绝对布局改变时，不会影响普通文档流的 render tree，但是依然会绘制整个默认复合图层，对普通文档流是有影响的。普通文档流就是默认复合图层，不要介意我交换使用它们如果你要使用硬件加速方式降低重排的影响，请不要过度使用，创建新的复合图层是有额外消耗的，比如更多的内存消耗，并且在使用硬件加速方式时，配合 z-index 一起使用，尽可能使新的复合图层的元素层级等级最高。
（1）transform
（2）opacity
（3）filter
（1）内存。如果GPU加载了大量的纹理，那么很容易就会发生内存问题，这一点在移动端尤为明显。
（2）使用GPU渲染会影响字体的抗锯齿效果。这是因为GPU和CPU具有不同的渲染机制，即使最终硬件加速停止了，文本还是会在动画期间显示的很模糊。
1、transform会使用GPU硬件加速，性能更好，position + top/left会触发大量的重排重绘，性能影响较大。
2、硬件加速的工作原理是创建一个新的复合图层，然后使用合成线程进行渲染
3、3D和2D动画的区别，2D动画会在动画开始和动画结束时触发2次重新渲染
4、使用了GPU可以优化动画小故宫但是不要滥用，会有内存问题
5、理解强制触发硬件加速的transform技巧，使用对GPU友好的CSS属性
参考文章： https://zhuanlan.zhihu.com/p/78230297
el-scrollbar是elementui自带的页面滚动条，如果用页面滚动条，我们发现在ie浏览器下卡顿很明显，但是用el-scrollbar滚动页面就会感觉会流畅很多，因为页面滚动会引发重排重绘，但是el-scrollbar是用transform不会引起，所以用el-scrollbar会感觉流畅很多，转订单去掉overflow:hidden就会流畅是因为这个样式会覆盖el-scrollbar的样式，
CSS优化包括很多方面，写CSS很简单很容易，但是要想写出精炼的CSS代码还是有很多技巧的。随便讲一下，不对的地方多多指正：
1、避免过度约束
// 糟糕ul#nav{..}
// 好的
#nav{..}
2、后代选择符最烂
// 烂透了html div tr td {..}
3、避免链式（交集）选择符
// 糟糕.menu.left.icon {..}
// 好的
.menu-left-icon {..}
4、使用复合（紧凑）语法
// 糟糕.someclass {
padding-top: 20px
padding-bottom: 20px
padding-left: 10px
padding-right: 10px
background: #000
background-image: url(../imgs/carrot.png)
background-position: bottom
background-repeat: repeat-x
}
// 好的
.someclass {
padding: 20px 10px 20px 10px
background: #000 url(../imgs/carrot.png) repeat-x bottom
}
5、避免不必要的命名空间
// 糟糕.someclass table tr.otherclass td.somerule {..}
//好的
.someclass .otherclass td.somerule {..}
6、避免不必要的重复
.someclass {color: red
background: blue
font-size: 15px
}
.otherclass {
color: red
background: blue
font-size: 15px
}
// 好的
.someclass, .otherclass {
color: red
background: blue
font-size: 15px
}
7、最好使用表示语义的名字。一个好的CSS类名应描述它是什么而不是它像什么。
8、避免 !importants，其实你应该也可以使用其他优质的选择器。
9、尽可能精简规则，你可以进一步合并不同类里的重复的规则。
好吧，我就总结这9点吧，如果还有好的规则，请贴上来~~~
移动互联网时代，用户对于网页的打开速度要求越来越高。首屏作为直面用户的第一屏，其重要性不言而喻。优化用户体验更是我们前端开发非常需要 focus 的东西之一。
从用户的角度而言，当打开一个网页，往往关心的是从输入完网页地址后到最后展现完整页面这个过程需要的时间，这个时间越短，用户体验越好。所以作为网页的开发者，就从输入url到页面渲染呈现这个过程中去提升网页的性能。
所以输入URL后发生了什么呢？在浏览器中输入url会经历域名解析、建立TCP连接、发送http请求、资源解析等步骤。
http缓存优化是网页性能优化的重要一环，这一部分我会在后续笔记中做一个详细总结，所以本文暂不多做详细整理。本文主要从网页渲染过程、网页交互以及Vue应用优化三个角度对性能优化做一个小结。
首先谈谈拿到服务端资源后浏览器渲染的流程：
关键渲染路径是浏览器将 HTML、CSS、JavaScript 转换为在屏幕上呈现的像素内容所经历的一系列步骤。也就是我们刚刚提到的的的浏览器渲染流程。
为尽快完成首次渲染，我们需要最大限度减小以下三种可变因素:
首先，DOM 和 CSSOM 通常是并行构建的，所以 CSS 加载不会阻塞 DOM 的解析。
然而，由于 Render Tree 是依赖于 DOM Tree 和 CSSOM Tree 的，
所以他必须等待到 CSSOM Tree 构建完成，也就是 CSS 资源加载完成(或者 CSS 资源加载失败)后，才能开始渲染。因此，CSS 加载会阻塞 Dom 的渲染。
由此可见，对于 CSSOM 缩小、压缩以及缓存同样重要，我们可以从这方面考虑去优化。
当浏览器遇到 script 标记时，会阻止解析器继续操作，直到 CSSOM 构建完毕，JavaScript 才会运行并继续完成 DOM 构建过程。
当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility 等），浏览器会将新样式赋予给元素并重新绘制它，这个过程称为重绘。
回流（Reflow）
当 Render Tree 中部分或全部元素的尺寸、结构、或某些属性发生改变时，浏览器重新渲染部分或全部文档的过程称为回流。
有时即使仅仅回流一个单一的元素，它的父元素以及任何跟随它的元素也会产生回流。现代浏览器会对频繁的回流或重绘操作进行优化：浏览器会维护一个队列，把所有引起回流和重绘的操作放入队列中，如果队列中的任务数量或者时间间隔达到一个阈值的，浏览器就会将队列清空，进行一次批处理，这样可以把多次回流和重绘变成一次。
当你访问以下属性或方法时，浏览器会立刻清空队列:
因为队列中可能会有影响到这些属性或方法返回值的操作，即使你希望获取的信息与队列中操作引发的改变无关，浏览器也会强行清空队列，确保你拿到的值是最精确的。
避免频繁操作样式，最好一次性重写 style 属性，或者将样式列表定义为 class 并一次性更改 class 属性。
避免频繁操作 DOM，创建一个 documentFragment，在它上面应用所有 DOM 操作，最后再把它添加到文档中。
也可以先为元素设置 display: none，操作结束后再把它显示出来。因为在 display 属性为 none 的元素上进行的 DOM 操作不会引发回流和重绘。
避免频繁读取会引发回流/重绘的属性，如果确实需要多次使用，就用一个变量缓存起来。
对具有复杂动画的元素使用绝对定位，使它脱离文档流，否则会引起父元素及后续元素频繁回流。
图片懒加载在一些图片密集型的网站中运用比较多，通过图片懒加载可以让一些不可视的图片不去加载，避免一次性加载过多的图片导致请求阻塞（浏览器一般对同一域名下的并发请求的连接数有限制），这样就可以提高网站的加载速度，提高用户体验。
将页面中的img标签src指向一张小图片或者src为空，然后定义data-src（这个属性可以自定义命名，我才用data-src）属性指向真实的图片。src指向一张默认的图片，否则当src为空时也会向服务器发送一次请求。可以指向loading的地址。注意，图片要指定宽高。
当载入页面时，先把可视区域内的img标签的data-src属性值负给src，然后监听滚动事件，把用户即将看到的图片加载。这样便实现了懒加载。
事件委托其实就是利用JS事件冒泡机制把原本需要绑定在子元素的响应事件（click、keydown……）委托给父元素，让父元素担当事件监听的职务。事件代理的原理是DOM元素的事件冒泡。
优点：
例如有一个列表需要绑定点击事件，每一个列表项的点击都需要返回不同的结果。
传统写法：
传统方法会利用for循环遍历列表为每一个列表元素绑定点击事件，当列表中元素数量非常庞大时，需要绑定大量的点击事件，这种方式就会产生性能问题。这种情况下利用事件委托就能很好的解决这个问题。
改用事件委托：
输入搜索时，可以用防抖debounce等优化方式，减少http请求；
这里以滚动条事件举例：防抖函数 onscroll 结束时触发一次，延迟执行
节流函数：只允许一个函数在N秒内执行一次。滚动条调用接口时，可以用节流throttle等优化方式，减少http请求；
下面还是一个简单的滚动条事件节流函数：节流函数 onscroll 时，每隔一段时间触发一次，像水滴一样
参考链接： https://zhuanlan.zhihu.com/p/113864878?from_voters_page=true
