第 145 题：前端项目如何找出性能瓶颈
igoryaodev opened this issue · comments
性能分析、定位
前提：项目中引入了很多第三方库，突然有天测试发现某个可视化页面长时间不关闭会造成浏览器奔溃
造成浏览器奔溃，可在浏览器的 devtool 里一项项排查，查看临近奔溃时间段的 performance 里的运行状态，跟进片段的脚本调用。
包括 Memory 也是可以分析的（一种思路，个人暂时不精）
性能监控体系, chrome perfermance devtools, 工作经验
遇到问题了，而且还是性能问题，瓶颈就是当前无法很好的解决。
这什么问题啊？？？？？
分享一下我近期的经验，之前项目也碰到过用起来很卡的情况，就是用element ui的tab切换组件时，点击tab切换非常卡，非常耗时，在排除了网络请求和js代码执行时间过长等原因后，跑了一次perfermance，结果发现大部分时间都花费在了 DOM GC上了，分析了下原因可能时dom结构太多导致每次tab切换渲染太耗时了。由于我每个tab里面的html结构都一样，都是一个table，只是每次tab切换时请求的数据不一样，我就把table抽离出来了，放到tab组件外面，然后tab里面就空了，就没有那么多dom了，tab切换就不卡了，很流畅。（ps：tab有20-30个切换选项，本人语文水平不行，描述的不清楚，望轻喷。）
根据Chrome的perfermance 判断哪里用的时间比较多,是DOM重绘还是js事件执行
我觉得应该首先理一理会造成性能损耗的一些场景:
- 比如大列表的渲染,大量dom的渲染
2.大量图片的加载,过多资源的请求.
3.代码中有没有耗时的计算操作,或则大量循环.递归 - 编写的组件过于庞大 层级过深,依赖模块过多等.
我觉得首先就是查看请求的资源体积是否过大,如果过大考虑压缩,减少不必要的资源的请求,不必要的js代码的代码加载,用字体图标代替图片,异步加载等等.
但是我觉得基本的优化策略(减少请求数,压缩请求资源的体积)都已经做过了,感觉性能还是没有提升,可能应该关注与代码层面的优化吧,比如过大的第三方库能不能换成轻量级的,代码中有没有很耗时的操作循环和递归,过多的分支条件语句,能不能改写以提高执行效率,简化复杂的组件逻辑,减少不必要的依赖,是否有杀鸡用了牛刀的操作等.暂时想到的就这些.
我觉得其实也可以在业务层面考虑,是否有必要耗费很多性能去实现某一个交互,这个交互可能会很耗费性能,且比较难以优化的,那么就要权衡一下.或者有没有别的其他方式的交互,不需要耗费很多性能的交互呢.
分享一下我近期的经验，之前项目也碰到过用起来很卡的情况，就是用element ui的tab切换组件时，点击tab切换非常卡，非常耗时，在排除了网络请求和js代码执行时间过长等原因后，跑了一次perfermance，结果发现大部分时间都花费在了 DOM GC上了，分析了下原因可能时dom结构太多导致每次tab切换渲染太耗时了。由于我每个tab里面的html结构都一样，都是一个table，只是每次tab切换时请求的数据不一样，我就把table抽离出来了，放到tab组件外面，然后tab里面就空了，就没有那么多dom了，tab切换就不卡了，很流畅。（ps：tab有20-30个切换选项，本人语文水平不行，描述的不清楚，望轻喷。）
你写代码的时候没 考虑好呀
性能瓶颈一般是表现在用户体验方面，比如页面加载过慢，动画卡顿，交互延迟等等，具体问题具体分析。
比如PM反馈说，你们这个页面怎么加载这么慢啊，好几秒才呈现，这种现象问题可能出现在请求资源过多，资源太大，没有压缩，没有缓存等等，那么就等减少http请求，压缩资源，设置缓存。
如果PM反馈说，这个列表滑动的时候加载数据一卡一卡的，那么性能瓶颈可能出现在频繁操作，数据太大等等，那么就得做懒加载，函数节流等等；
总之前端的性能瓶颈往往都是有表现的，需要针对具体表现具体分析具体解决
Lighthouse
我最近遇到的，vis的关系图，在跑大数据量时，浏览器卡死，手动销毁也没有效果，，通过chrome performance监控，发现是绑定了太多的监听，在销毁时把监听也都销毁了，，但是有关渲染时的卡顿，目前还没找到好办法（已经去掉了物理vis本身的物理引擎）
大数据量列表渲染的时候，比如点餐，外卖，电商分类列表等。当数据量达到一定程度且每条数据里面的都有对应的效果和图片以及操作等等。这时候上下拉的时候就会出现延迟，甚至点击无反应。
这时候就是前端(浏览器)渲染的性能瓶颈了。
当然解决的方式可以把数据切块，分块进行加载，加载到某一块的时候取某一块的数据，其他的隐藏，这样则可以解决大数据列表的问题。
为了体验好，可以把渲染区域上下两屏的数据都渲染出来，以防出现空白。
小程序的话，还可以通过开发者工具的Audits来查看。
我最近遇到的，vis的关系图，在跑大数据量时，浏览器卡死，手动销毁也没有效果，，通过chrome performance监控，发现是绑定了太多的监听，在销毁时把监听也都销毁了，，但是有关渲染时的卡顿，目前还没找到好办法（已经去掉了物理vis本身的物理引擎）
现在怎么样了，我也有这个问题
第三方性能测试网站：https://gtmetrix.com/
分享一下我近期的经验，之前项目也碰到过用起来很卡的情况，就是用element ui的tab切换组件时，点击tab切换非常卡，非常耗时，在排除了网络请求和js代码执行时间过长等原因后，跑了一次perfermance，结果发现大部分时间都花费在了 DOM GC上了，分析了下原因可能时dom结构太多导致每次tab切换渲染太耗时了。由于我每个tab里面的html结构都一样，都是一个table，只是每次tab切换时请求的数据不一样，我就把table抽离出来了，放到tab组件外面，然后tab里面就空了，就没有那么多dom了，tab切换就不卡了，很流畅。（ps：tab有20-30个切换选项，本人语文水平不行，描述的不清楚，望轻喷。）
不可见 tab content 切换的时候销毁吗?
分享一下我近期的经验，之前项目也碰到过用起来很卡的情况，就是用element ui的tab切换组件时，点击tab切换非常卡，非常耗时，在排除了网络请求和js代码执行时间过长等原因后，跑了一次perfermance，结果发现大部分时间都花费在了 DOM GC上了，分析了下原因可能时dom结构太多导致每次tab切换渲染太耗时了。由于我每个tab里面的html结构都一样，都是一个table，只是每次tab切换时请求的数据不一样，我就把table抽离出来了，放到tab组件外面，然后tab里面就空了，就没有那么多dom了，tab切换就不卡了，很流畅。（ps：tab有20-30个切换选项，本人语文水平不行，描述的不清楚，望轻喷。）
为什么抽出来就不卡了
首先先判断哪里出现了性能瓶颈
1.资源加载 -> 首次需要下载的量是否过大 是否需要懒加载 缓存配置是怎样的 单页面是否过大需要分页
2.网络请求 -> 请求时间是否过长 数据是否可以缓存 需要计算的数据是放到服务端还是客户端
3.运行卡顿 -> 运行环境的支持版本如何 运行环境的性能如何 是否存在内存泄漏 dom元素是否过多 动画安排是否合理
如果依赖大量的计算的话，也可以采用纯函数的形式，将函数的计算结果缓存起来，只在第一次call的时候运行，之后的取值都从缓存里面拿
为什么遇到性能瓶颈，真的有必要去解决吗？个人觉得可以从两个维度去思考：
①交互设计上：很多情况下，交互设计存在导致页面出现性能瓶颈的问题，在实际应用中，是否可以考虑优化现有交互，比如：列表，是否可以分页？地图撒点，是否可以通过点聚合实现？树型视图，是否可以在交互上懒加载，而不是一次性加载所有？这些类似的场景都不需要直接通过研究底层技术去实现优化，这种方式个人认为是应该优先考虑的。
②技术上：如果已经要考虑这个层面的优化了，证明你已经向产品或者交互妥协，那就专业的研究下在既定场景下，导致性能问题的因素都有哪些？如：加载的资源中重复代码过多，使得文件太大、业务设计不合理导致请求过多、代码编写不规范，造成不必要的浏览器计算，及服务端计算，浪费运行资源、业务代码中关于组件实现上，内部涉及业务的算法上是否有优化的空间、对应用的技术栈理解的不够深入，在使用过程中不合理的运行了一些不必要的框架内部程序，从而导致整个业务单元运行效率降低，从而产生用户可以感知的性能问题。
简而言之：交互优化优先级高于技术性优化