从用户的角度而言，当打开一个网页，往往关心的是从输入完网页地址后到最后展现完整页面这个过程需要的时间，这个时间越短，用户体验越好。所以作为网页的开发者，就从输入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
最近自己做一些threejs项目，总结了一些性能优化的关键点，跟大家分享一下。
1、尽量使用clone方法；
2、不需要的时候一定要dispose；
3、优先使用BufferGeometry；
4、注意图片压缩；
5、重点优化requestAnimationFrame内的方法（描述一）；
6、如果有大量外部模型，一定要结合使用gltf-pipeline与Draco（描述二）。
如果涉及到需要使用animate，尽量在需要渲染的时候来执行内容：
首先，建议使用gltf或者glb来加载模型。如果有大量外部模型，一定要结合使用gltf-pipeline与Draco。
这很重要，有时候我们获得的gltf模型文件后，我们可以轻易的压缩图片；但有些scene.bin文件可以达到100M或200M以上，模型多了之后会很大程度影响使用体验。
结合使用gltf-pipeline与Draco，可以有效的压缩文件甚至在10M以下！
1、首先你要将three/examples/js/libs/draco文件夹放到public目录下！
2、进入需要压缩的gltf模型文件，执行gltf-pipeline -i scene.gltf -o sceneDraco.gltf -d
执行成功后删除原先的.gltf .bin文件
如果没有安装过gltf-pipeline，使用npm全局安装即可
https://github.com/aisriver
最近在项目中使用Cytoscape.js、D3.js和DataV等前端绘图库。
图形常见的操作有拖拽、缩放、平移等。
页面出现这些动作事件后，这些绘图库都会抛出一个hook，然我们有机会根据业务需求，在合适的时机完成图形操作。
问题就来了，例如拖拽事件，用户拖拽一个节点是一个持续的过程，浏览器有可能1s中抛出好几百个“drag”事件。
如果每个“drag”事件，我们都去做绘制图形相关的计算，那么会浪费很多计算资源。
因为浏览器一般1s中最多也就绘制60次，也就是说，尽管我们1秒钟计算了好几百次，只有其中60次的计算结果能够展示在界面上，大部分计算都是无效的，白白浪费了计算资源。
那么有什么优化方法呢？
首先想到的是debounce或者throttle函数, 能够降低回调函数的执行频率。但缺点是，时间参数门限的选取比较纠结，参数大了，用户操作会有卡顿延时感；参数门限小了话，又有可能浪费性能。
最好的办法就是浏览器要绘制界面之前，完成相关的计算，这样不多不少，每个计算结果都能得到展示。
所以，最后的答案来了 —— window.requestAnimationFrame(callback) 。这个web API是前端应用绘图库的必备API，能够让用户有丝滑的交互体验，同时让计算开销降到最低。
