共计 2576 个字符，预计需要花费 7 分钟才能阅读完成。
笔者是一个六年前端，没有大厂经验，也没有什么出彩的我的项目，所以今年以来，前端当初这种行情下并没有收到多少面试，然而为数不多的面试中，百分之九十都问到了性能优化的问题，而且问题都出奇的统一：
平时的工作中你有做过什么性能优化？
对于这个问题其实我的心田 os 是（各位轻喷 \~）：
你们怎么都这么爱问性能优化的问题？我的简历中也没有写到这个啊。
你们的业务都这么简单吗？怎么动不动就要性能优化？
你们的代码写的这么拉吗？不优化都不能应用吗？
性能优化是一个高级前端的必要技能吗？
首先客观现实是笔者平时工作中的业务并不简单，须要性能优化的中央的确不多，一些存在性能瓶颈的大多是应用了其余团队开发的货色，比方播放直播视频的 SDK、3D 地图引擎等，也找过他们进行优化，然而没用，他们也优化不动。
所以每次被问到这个问题我就很难堪，说工作中没有遇到过性能问题，预计面试官也不信，间接说没有做过性能优化，那又显得我这个六年教训的前端太水了，连这个都不做，所以每次我只能硬说。
没吃过猪肉，还没见过猪跑吗？其实性能优化的文章我也看过很多，各种名词我还是晓得一点的，比方：
- 性能问题排查：
1. 数据埋点上报
2. 应用控制台的 NetWork、Performance 等工具
3.webpack-bundle-analyzer 插件剖析打包产物
- http 相干：
1.gzip 压缩
2. 强缓存、协商缓存
- 图片相干：
1. 图片压缩
2. 图片懒加载
3. 雪碧图、应用字体图标、svg
- webpack 相干：
1. 优化文件搜寻
2. 多过程打包
3. 分包
4. 代码压缩
5. 应用 CDN
- 框架相干：
1.vue 性能优化、react 性能优化
2. 异步组件
3.tree shaking
4. 服务端渲染
- 代码实现
1. 按需加载，逻辑后移，优先保障首屏内容渲染
2. 简单计算应用 web worker
3. 接口缓存、计算结果缓存
4. 预加载
5. 骨架屏
6. 虚构滚动
等等。
但这些绝大部分我并没有实际过，所以我都说不出口，说我没有机会实际也行，说我没有好奇心不好学不爱思考不被动发现问题也行，总之后果就是没有教训。
所以通常我硬着头皮只能说出以下这些：
1. 开发前会花点工夫梳理业务，全局视角过一遍交互和视觉，思考组件划分，找出我的项目中类似的局部，提取为公共组件和通用逻辑。
2. 代码开发中尽量保障写出的代码清晰、可保护，比方：清晰的目录和文件构造、增加必要的正文、提取公共函数公共组件、组件单向数据流、组件性能尽量繁多等。
3. 时刻关注可能会存在性能问题的局部，比方：
路由组件异步加载
动静加载一些初始不须要用到的资源
频繁切换的组件应用 KeepAlive 进行缓存
缓存简单或罕用的计算结果
对实时性不高的接口进行缓存
同一个接口屡次申请时勾销上一次没有实现的申请
页面中存在很多接口时进行优先级排序，优先申请页面重要信息的接口，并关注同一时刻申请的接口数量，如果过多进行分批申请
对于一些的确比较慢的接口应用 loading 或骨架屏
懒加载列表，懒加载图片，对移出可视区的图片和 dom 进行销毁
关注页面中应用到的图片大小，推动后端进行图片压缩
地图撒点时应用聚合缩小地图引擎渲染压力
对于一些频繁的操作应用防抖或节流
应用三方库或组件库尽量采纳按需加载，缩小打包体积
组件卸载时勾销事件的监听、勾销组件中的定时器、销毁一些三方库的实例
我工作中的实际也就以上这些，其实就是写代码的根本要求，另外我感觉如果业务简单，以上这些也并不能阻止性能问题的呈现，更多的还是当呈现了问题，去思考如何解决。
比方我开源的一个思维导图我的项目 mind-map，当节点数量多了会十分卡，调试剖析思考后发现起因是做法不合理，每次画布上有操作后都是清空画布上的所有元素，而后从新创立所有元素，数据驱动视图，原理非常简单，然而因为是通过 svg 实现，所以就是 DOM 节点，这玩意咱们都晓得，当节点数量十分多当前，删除节点和创立节点都是十分耗时的，所以数据驱动视图的框架，比方 Vue 会通过虚构 DOM 的 diff 算法比照来找出最小的更新局部，然而我没有做。。。所以。。。那么我就天然的做了一些优化，比方：
思维导图场景，大部分状况下操作的其实就是其中一个或局部节点，所以不须要从新删除创立所有元素，那么就能够通过节点复用的形式来优化，将实在节点缓存起来，渲染时通过数据惟一的 id 来查看是否存在可复用节点，如果没有，那么代表是新增节点，那么创立新节点即可；如果有，那么就判断节点数据是否产生扭转，没有扭转间接复用，如果产生了扭转那么判断是否能够进行更新，如果更新老本高那么间接从新创立；另外也须要和上一次的缓存进行比照，找出本次渲染不须要的节点进行删除；当然，为了防止缓存节点数量有限收缩，也通过 LRU 缓存算法来治理
对于不影响其余节点的操作只更新被操作的节点
通过
setTimeout异步渲染节点，留一些两头工夫来响应页面其余操作将触发渲染的工作放到队列中，在下一帧进行解决，合并掉一些中间状态
对于鼠标挪动和滚动的场景，通过节流来优化
进行一些取舍，晚期节点激活时能够批改节点的所有款式，导致激活操作须要从新计算节点大小，更新节点款式，在多选和全选操作下十分耗时，所以前期改为只容许批改不扭转节点大小的款式属性
其余一些细节优化：对于数据没有扭转的操作不触发赋值或函数调用，一些不起眼的操作可能也是须要消耗工夫的；扭转了不波及节点大小的属性不触发节点大小从新计算等
通过以上这些批改后，性能的确有了很大水平的晋升，不过有些我的项目能够通过一直的优化来晋升性能，然而有些可能就是设计缺点，比方我开源的另一个白板我的项目，更好的形式其实是重做它。
写到这里其实并没有解决本文题目提出的问题：
为什么面试官这么爱问性能优化？
因为我没有怎么做过面试官，甚至面试教训其实都不太多，写这篇文章目标次要有两个：
1. 想听听有面试官教训的各位的想法或倡议
2. 想看看和我有相似状况的面试者面对这个问题，或者说相似的问题是如何答复的
最初再牢骚几句：
有时会感叹工夫过的真快，一转眼，作为一个前端曾经工作了六年，行将三十而立却立不起来，这么多年的工作，更多的只是播种了六年的经验，然而并没有六年的能力，回过头看，当初的有些抉择的确是谬误的，兴许这就是人生把。
作为一个一般的前端，在现在的行情下面试的确很艰巨，尤其是我这种不善于面试的人，不过话说回来，扭转哪有不苦楚的，除了面对也没有其余方法。