前情先简单介绍下，本人于2021年10月找工作期间，在关于项目亮点问题上产生了忧虑，感觉自己做得都是简单内容，由于做得都是业务，且大部分是后台管理型系统，所以很茫然。这是想到了之前项目中出现过的卡顿现象，于是就想到了性能优化这个方面，结果遭到了字节大佬的暴击，根本不敢说自己做过性能优化。于是我多方查找资料，在此节选了感觉讲的最好的【方应杭】老师的文案，希望能给有需要的同行写帮助。这里我还会加上自己的一些观点，如有错误请轻喷：
性能优化的背景
性能瓶颈主要出现在三个场景
- 在开发时每次修改代码打包需要几分钟，太慢（开发构建阶段）
- 打开网站，等了几十秒才看到页面，太慢（资源加载和页面渲染阶段）
- 页面展现后，页面上动画不流畅。滚动页面或者拖拽元素卡顿感严重，甚至页面会崩溃（操作体验阶段）
处理方式
处理的思路如下：
一、开发构建阶段（常见问题：如何让Webpack打包更快）
- 并发：使用多进程打包
- 缓存：打包时利用缓存
- 打包量要小：缩小文件搜索范围，减小不必要的编译工作
二、资源加载阶段
核心思路是：传输量要小、距离要近、并行传输、资源复用。
传输量要小
- 构建时HTML压缩
- 构建时CSS压缩合并
- 构建时JavaScript压缩合并
- 构建时图片的压缩
- 使用SVG sprite 或者字体图标代替图片ICON
- 服务端开启Gzip，数据在传输之前再次压缩
- 构建时是使用TreeShaking，减少不必要的代码引入
- 单页应用路由懒加载，减少首次加载的资源体积
- 组件懒加载，减少首次加载的资源体积
- 图片懒加载，减少首次加载的资源体积
距离要近
- 静态资源部署到CDN
并行传输
- 升级到 HTTP2.0 （常见问题：HTTP2.0相比HTTP1.x做了哪些升级？多路复用；二进制分帧；服务端推送；数据流优先级；头部压缩）
资源复用
- 服务端配置静态资源缓存（常见问题：
HTTP缓存策略？Cache-Control？keep-alive？304？ETag？） - 打包时分包复用
三、页面渲染阶段
- CSS在上、JS在下
- 加载CSS推荐用 link 少用 @import
- 不重要的外置引入的JS使用defer或者async属性异步加载
四、操作体验阶段
动画流畅
- 尽量使用 transition 和 animation来实现CSS动画 ， 而不是JS实现动画（运行在主线程对动画的流畅度有影响）
- 动画尽量多用transfrom 和 opacity （无需重绘和回流，性能最好）
- translateZ/translate3d 开启硬件加速
- JS动画使用
requestAnimationFrame少用setInterval
滚动/移动/操作流畅
- DOM增删操作要少(虚拟长列表、DOM Diff)
- 高频操作使用防抖和节流
密集型计算
- 计算密集型操作可以交给WebWorker并发处理
综上所述：性能的6字箴言：压缩、缓存、并发。围绕着他们答总没错。
补充些内容：
-
1-2 关键点在于webpack的cache相关内容
-
1-3 关键点在于webpack的resolve查询路径，cacheable判断是否要编译等
-
2-* 用【webpack-bundle-analyzer】来分析你引用的哪个插件大，需要按需引入。
-
4-2 关于虚拟滚动，这块面试也比较容易问，简单说下思路.拉取全部资源，这块可能会导致慢的问题。通过计算总高度，通过渲染一个高度相同的盒子达到使滚动条和正常渲染一致，然后再
监听scroll事件并根据滚动距离，算出要渲染的内容，并使用transform：translateY或者top等来不断调整位置，并呈现在视口。优化点：
- 要是通过
监听scroll事件的方式来触发可视区域中数据的更新，当滚动发生后，scroll事件会频繁触发，很多时候会造成重复计算的问题，从性能上来说无疑存在浪费的情况。当然简单点做个节流就好了；这里需要给大家介绍的是IntersectionObserver替换监听scroll事件，IntersectionObserver可以监听目标元素是否出现在可视区域内，在监听的回调事件中执行可视区域数据的更新，并且IntersectionObserver的监听回调是异步触发，不随着目标元素的滚动而触发，性能消耗极低。 - 如果是
简单高度相同的列表的虚拟滚动可以直接通过计算得出总高度，否则如图片列表等高度不同的内容，则需要记录每个子级节点的高度，再进行计算平移位置。
- 要是通过
