##性能优化 = 1你写的代码（大小、算法执行的效率） + 2你用的文件（图片的选择） + 3输入url请求到页面渲染结束这个过程。 上联：琐琐碎碎，下联：碎碎琐琐，横批：巨琐碎。 基本的优化做好之后，更多的是权衡。
##：你写的代码（文件大小、个数、算法执行的效率）
·其实就是资源的合并与压缩（html/css/js)，减少网络请求的个数，减少每次请求的大小。
·优化代码结构：例如最常用的防抖和节流，两种都可以用，但是要注意场景，
·防抖：是再次触发时，清除之前的定时器，再创建一个定时器，重新计算时间。
·节流：是触发的定时器的回调函数执行后，才能再次触发此定时器，所以在最后一个定时器线程等待时间结束，
然后添加到事件触发线程控制的事件队列这个过程中，如果有事件，是没办法触发的；
举例：在vue中使用better-scroll时会因为图片的加载，而经常导致无法滚动的情况，原因是html解析完成，触发Domcontentload之后
，你这个dom高度就有了，是多少呢，是0，所以部分DOM无法撑起高度，这就需要在图片加载发射load事件后，调用better-scroll库
的refresh方法，刷新一下高度，每次图片加载就调用，未免太多了，这里就不好用节流了。
-
算法：
可以直接跑一遍，但是传入的参数不同，环境不同，结果都可能不一样 2、复杂度分析，函数随着传入参数的越来越大，函数执行行数的变化规律，又得是正比，有的是正弦，一元二次等等 ；算法垃圾的我我就先不记录了，后续肯定会更新的。 -
减少重绘与回流
从performance可以监控到回流的过程：relac重新计算 > layout重新布局 > update...ertree更新回流树 > paint重绘生成图层 > composite layers图层合成。这里的图层就跟ps里的图层类似，众多图层组成一张海报、图片。 优化点： ·用translate替代top； ·用opacity替代visibility，opacity是控制类似ps里面的apha值来控制透明度，不会导致重绘 ·修改一个dom的样式不要一条一条的修改，可以先离线（display：none），再上线，；或者class集体修改 ·不要把dom节点的属性放在循环里当作变量 ·获取节点的offsetscroll还有client等会早上回流，更要注意不能把它放到循环里当作变量 ·不要使用table布局，当table内的dom发生回流时，会导致laout布局是整个table节点，table节点复杂，laout时间就会长 ·对于必须要频繁回流重绘的元素，创建单独的图层，方式will-change:transfrom，video标签，transfrom: translate-z(0)，滥用图层可能起反作用。 这里有个关于浏览器事件循环的小知识点，假如你设置了一个定时器，在1000ms里，频繁触发回流800次，理论就是800次回流，其实不是，受制于两个因素，1 浏览器的刷新帧率（1秒60次）， 2 事件循环，需要时间
##你用的文件（图片的选择）
图片的选择有：jpg/png/gif/webp/svg/精灵图/base-64
他来了，他来了，权衡的时候到来了
jpg：比较小，显示也不错，但图标类的，显示不行，颗粒感明显，不支持透明，使用率最高；
png：文件非常大，显示非常好，有32、64位编码格式，越高显示的越好喽，支持透明，用于较高要求时；
gif：动图就用它了；
webp：啥都好，文件小、显示好、支持透明、动图、但是但是兼容性不好；
精灵图：减少http请求数量，但是你这一个没请求到，出问题了，很多地方就歇菜了；
base-64：把图片编码成文本，放在src处，减少http请求，但是体积会提升30%左右，一般只用于很小很小的图标、图片；
svg：可以放在src处和当成标签用，适合制作简单图标；
##输入url请求到页面渲染结束这个过程
（大致流程） 0 输入url回车浏览器进程会补齐协议，生成完整的url，然后发送到网络进程，网络进程会查找本地是否有缓存，有则返回 > 1 DNS解析出网络层需要的ip，可缓存 > 2 TCP3次握手，建立连接，响应头可以设置keep-alive，传输完成后tcp不关闭，后续可以依次使用 > 3 HTTP请求协议和TLS协议保障安全，构建请求行，头，体 > 4返回响应文件 > 5 解析、请求、执行、渲染
-
DNS可以缓存，如果没有会去DNS服务器去找
-
TCP断开时的4次挥手，第三第四次可以合并；
-
HTTP请求我们用的都是1.x的
静态资源都放在CDN上面 http1.0对于同一个域名同一时间的请求有一个并行请求上限（谷歌是6个），超过上限就会排队，所以CDN的域名有时候要用好几个 请求的资源可以在开启缓存，（这个需要后端来搞） 缓存位置有cookie（4k）、localstorage（7M）、sessionstorage（7M，页面关闭就没得了）、indexDB（放大型数据） 缓存方式有：强缓存、协商缓存；强缓存：Expires（是老版本的过期时间，依赖电脑本地时间，所以不太可靠）、cache-control（优先级高） 协商缓存：Last-Modified（打开本地缓存文件就改变）、Etag（优先级高、更聪明），然后对比服务器的文件修改时间 下面为科普，记录下 http 2.0用上了多路复用，请求头部压缩，从原来的文本传输，升级为二进制传输，现在只需要一个TCP连接就可以了，这里的一个TCP和http 1.x不一样，这个是并行请求，1.x是依次请求 极大的增加了效率，和减少了很多以前的优化过程，but 一旦丢包，就连1.0的都不如了 http 3.0基于了UDP传输协议创建的QUIC协议，还集了上面的优点 -
拿到html之后，在网络中传输都是字节流，浏览器会先转换为字符流，然后开始解析
遇到html、body、div等会生成dom树，遇到css树会生成css树，遇到js会看有没有defer、sync，如果啥也没有， 等下载好之后，就会立即执行，阻塞后面的解析；如果有sync属性，会等待下载，下载好立即执行，部分顺序； 如果有defer属性，会等待html解析完毕后，依次加载执行；css也是会阻塞页面你的渲染的，当css在header标签中时， 如果css放在body底部，可能会造成短暂白屏。
以上就是一些关于我理解性能优化的知识点，当然只是冰山一角，如有大佬出没，请留下脚印，，后面有时间会更新浏览器的工作原理，事件循环等。
