本文目录一览：
渲染机制、回流、重绘
解析 HTML 标签, 构建 DOM 树
解析 CSS, 构建 CSSOM 树
把 DOM 和 CSSOM 组合成渲染树 (render tree)
在渲染树的基础上进行布局, 计算每个节点的几何结构
把每个节点绘制到屏幕上 (painting)
Reflow：重新计算元素的几何尺寸、位置 + repaint
Repaint：绘制界面发生变化的部分
(回流会引起重绘，所以代价更大)
添加、删除、更新DOM节点(reflow、repaint)
修改元素的magin、padding、border（reflow、repaint）
display: none（reflow、repaint）
visibility: hidden（repaint）
修改颜色、背景色 (repaint)
尽量一次性修改样式
DOM离线后修改
给动画使用绝对定位可以减小 reflow ？
javascript - What's the difference between reflow and repaint? - Stack Overflow
js优化中，离线操作dom中的“离线”怎么理解？ - SegmentFault 思否
浏览器中动画渲染效率原生js高还是css高？
css的执行顺序是优先于js的，
css一旦被引入，立即存到浏览器内存中，
动画的话，当然是css高
浏览器的渲染过程及涉及到的缓存机制
答：dns解析-》tcp链接-》发送HTTP请求-》服务器处理请求并且返回报文-》浏览器解析渲染页面-》链接结束
是一个将网址解析成IP 地址的过程。
首先从本地域名服务器中查找，如果找不到就继续向上根域名服务器查找，直到顶级域名，这个过程中存在dns优化有的环节。当查找资源时， 会先找缓存，（浏览器缓存-》系统缓存-》路由器缓存等等），也会根据机器的负载量和距离用户的位置进行dns负载均衡。
A.客户端发送syn到服务器要求连接
B.服务端向客户端发送ack
C.客户端收到ack并确认后，向服务端发送ack，连连接建立。
tcp连接建立之后，开始通过HTTP协议传输资源，根据情况判断是否使用HTTPS，HTTP包括请求行，请求报头，请求正文（post，put客户端向服务器传输数据的情况）。keepalive什么的可以在请求头里添加。
（此处涉及强制缓存和协商缓存， 为了先讲清楚浏览器渲染过程，我把他们放在文章末尾。）
服务端接到请求开始对tcp进行处理，对http进行解析，按照报文格式封装成HTTP request对象。响应报文码（1xx：请求已接受，2XX：成功，3xx：重定向，4xx：客户端错误，5xx：服务端错误）
边解析边渲染，首先解析html,构建dom树，然后解析css，构建cssom。
我思考过很久HTML和css谁先渲染。我的理解是，不一定，看位置了，如果dom构建的过程中遇到了css的link，那就会先去加载并构建cssom，这个过程不是一次性的。 css和同步的js文件都是阻塞DOM树渲染的，但不阻塞DOM解析， 直到js加载并且执行完毕。遇到阻塞的css也会延迟js的执行和dom构建。（因为js可能会修改dom或者cssom）,css同样，当cssom构建时，js也会停止被阻塞，等待cssom构建完成。
defer async
1.正常模式
script src="script.js"/script
遇到这样的js标签，浏览器会立即加载并执行，不等待后续载入的文档元素。
2.async模式
script async src="script.js"/script
有async的js文件会和后续的DOM解析渲染并行执行，当js加载完成，立即执行，这时html解析暂停。因此不会按照标签引入顺序执行。
3.defer模式
script defer src="script.js"/script
有defer的js文件的加载，也会和文档的解析构建并行。这一点与async一致。
不同的是，defer的js文件加载完不会立即执行， 会等到所有文档解析完成后，DOMContentLoaded事件触发之前完成， 因此会按照引入顺序执行。
DOMContentLoaded onload
DOM解析完（阻塞DOM的内容解析完，DOM才真正解析完）会触发DOMContentLoaded事件。如果在DOMContentLoaded之后引入css样式表，DOMContentLoaded可能无法获取样式表里的样式，此时DOM树已经构建完成，但外部css文件还没加载完成，这也是 css文件放在头部的原因 。
onLoad
页面的所有资源被加载以后触发onLoad事件，会在DOMContentLoaded之后触发。
这个过程中有两个重要的过成是回流和重绘。计算盒模型的大小位置还有解析颜色字体等 属性，这些都确定下来的时候开始repain，合成一个rendertree渲染树，render-tree中必须同时存在dom和cssom，浏览器开始布局并渲染到屏幕上。首次加载必然会经历回流和重绘的过程。
无论何时总会有一个初始化的页面布局伴随着一次绘制。（除非你希望你的页面是空白的:)）之后，每一次改变用于构建渲染树的信息都会导致以下至少一个的行为：
部分渲染树（或者整个渲染树）需要重新分析并且节点尺寸需要重新计算。这被称为重排。注意这里至少会有一次重排-初始化页面布局。
由于节点的几何属性发生改变或者由于样式发生改变，例如改变元素背景色时，屏幕上的部分内容需要更新。这样的更新被称为重绘。
重排和重绘代价是高昂的，它们会破坏用户体验，并且让UI展示非常迟缓。
一些重排可能开销更大。想象一下渲染树，如果你直接改变body下的一个子节点，可能并不会对其它节点造成影响。但是当你给一个当前页面顶级的div添加动画或者改变它的大小，就会推动整个页面改变-听起来代价就十分高昂。
浏览器一直致力于减少这些消极的影响，浏览器会创建一个变化的队列，浏览器可以向队列添加或变更这些变化，在一个特定的时间或达到一定的数量时，执行一次重排或重绘，通过这种方式，多次重排或重绘会整合起来最终减少重排或重绘的次数，以节省浏览器渲染的开销。
所以 ，同时set和get样式是非常糟糕的做法
看到的一个答案，有可能是这个原因，但是我不确定。
开发环境会把css都打包到js里，所以要等js加载好了才有样式，因此会出现这种情况；但是在生产环境下，css会生成css文件，并插入到style /里，因此就不会出现这种情况了。
两个优化点：css先加载，js后加载
js尽量不要修改dom树。
以下是我在OneNote的笔记，粘贴过来就会变成图片没有找到好的办法。
强制缓存和协商缓存是http请求这一步的内容。
前端性能优化总结(一)-js、css优化
移动互联网时代，用户对于网页的打开速度要求越来越高。首屏作为直面用户的第一屏，其重要性不言而喻。优化用户体验更是我们前端开发非常需要 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 时，每隔一段时间触发一次，像水滴一样
参考链接：
