概述
在浏览器中输入URL到页面加载完成发生了什么？
1. dns域名解析服务器进行ip解析
2. 建立http连接（三次握手）
3. 进行请求的发送
4. 服务器响应和结果返回
5. 客户端获取数据，解析结果，渲染页面，等待客户端操作
全部的性能优化都结合整个浏览器的响应过程，每一步都可进行相应的优化，达到性能最优。
大概可以分为两大部分，一部分是网络方面的性能优化（dns解析，http连接，网络请求），这部分前端工程师可做的较少，但也存在可为之处；另一部分则是浏览器方面的优化（数据缓存，资源加载优化，页面的构建和渲染等）
Part1 网络层面优化
打包优化
暂未使用。
图片优化
| 对比 | jpg/jpeg | png | svg | base4 | 雪碧图 | webp |
|---|---|---|---|---|---|---|
| 差异对比 | 有损压缩、体积小、加载快、色彩鲜明，不支持透明度 | 无损压缩、质量高、体积大、线条鲜明，支持透明度 | 文本文件、体积小、不失真、兼容性好 | 文本文件、依赖编码、小图标解决方案（将图片链接转化为图片编码） | 减少请求次数 | 综合各类图片性能 |
| 适用场景 | 需要图像质量较高的，较大的图片，如banner图 | 透明背景，线条鲜明，如logo | 矢量图形库 | 用于弥补不适合放在雪碧图中的小图标（转化后尺寸会是原来的4/3） | 多个图标组合 | 最优，但兼容性不好，要进行兼容处理 |
Part2 缓存层面优化
之前详细总结过，请参考 你必须知道的缓存机制。
Part3 渲染层面优化
1. 服务端渲染
服务端渲染
优点：提高seo，减轻客户端压力使响应很快
缺点：服务器成本高
2. 浏览器渲染
浏览器内核类型：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。
浏览器内核：分为渲染引擎和js引擎
浏览器渲染过程：解析html构建dom树 -> 解析css行程cssom树 -> 两合数结合计算页面内元素布局尺寸 -> 页面渲染 -> 渲染执行后续js脚本
<script>内脚本加载的三种方式：
1、不加参数，解析到script标签开始下载执行，会阻塞后面元素的加载和页面渲染
2、async 异步加载，遇到script开始下载，不阻碍后续节点的解析渲染，当下载完成后立即执行。
3、defer 遇到script开始下载，等待页面解析完成后执行
可优化点：
1、css加载会阻塞渲染，所以将css外链放入最顶
2、js是立即加载执行，会阻塞渲染过程，放在页面底部，等html和css全不解析完毕后执行
3、css少用通用匹配符号，少用标签选择器，最好用class
3、dom优化
相关知识点：
dom与js交互非常耗时
事件机制：宏任务，微任务（每次执行一个宏任务和所有微任务后会触发一次重新渲染）
回流与重绘
获取offsetTop、offsetLeft、 offsetWidth、offsetHeight、scrollTop、scrollLeft、scrollWidth、scrollHeight、clientTop、clientLeft、clientWidth、clientHeight 等一系列属性时，会触发回流
优化方向：
1.尽可能减少js与dom的交互通信
2.使用DocumentFragment代替直接对dom的操作，操作完成后在加入文档
3.离线dom，先将要改造的dom使用display:none；进行离线处理，在执行一系列操作，最后在设置为block，渲染进页面
4.将多个属性修改合并为一个class，通过class进行样式更新
5.利用事件循环的机制合理处理渲染事件
part4 应用篇
实现一个图片的懒加载
实现思路：
页面上的图片不渲染，当元素滚动到可视区域后，将对应图片渲染到容器中
滚动过程的优化涉及到防抖和节流的应用
函数节流和防抖请参考 节流和防抖
part5 性能监测
performance（概述面板，详情面板）
fps cpu net
可视化工具LightHouse
performance提供了一系列api可在全局中访问，可将其利用到代码中为后端提供性能监控