记一次前端性能调优
可以明显感觉到搜索结果页即使接口速度在500毫秒内返回还是有一阵卡顿感,部分电脑还会出现未响应整个Tab完全死掉的情况。
可以明显感觉到搜索结果页即使接口速度在500毫秒内返回还是有一阵卡顿感,部分电脑还会出现未响应整个Tab完全死掉的情况。
打开Chrome任务管理器可以明显看到这个Tab的CPU基本上大于30%,要知道我台式机E3都能跑50%,那么普通移动版笔记本的CPU应该是要爆炸了!通常CPU爆了表现为“Tab未响应”
打开开发者工具的Performance monitor,可以看到CPU使用一直很高,明细里Style recalcs / sec 一直高。
猜测应该是某个动画导致的!
问题排查
怎么定位具体哪个DOM呢?万能的排除大法!
肉眼可见的动画点,按钮呼吸灯动画
尝试删除监控按钮的闪烁动画DOM
CPU降至20%左右,但还是很高
尝试删除整个广告结果内容区域
CPU变化不大、Style recalcs依旧很高
尝试删除右边汇总边栏
CPU,Style recalcs显著降低!
经排查除按钮呼吸灯外,汇总边栏即使在不展开时,还有个两loading动画在运行,
这想必是问题所在!
问题处理
- 呼吸灯效果去掉或延迟开启,避免CPU的瞬时激增
- 汇总变栏在不展开时,关闭loading效果
看到这里你可能以为问题解决可以关机睡觉了?事实上并没有,尽管CPU降下来了,但是loading结束后的卡顿感依旧还存在的。
打开Network发现即使在接口返回400ms的情况下依旧有卡顿感。于是便尝试看了下接口调用前到loading结束一共消耗的总时间时间
即使接口在500ms返回的情况下到loading结束也是要花掉3.8s的。
打开Performence录制能看到XHR结束后有一段耗时的调用,明细都是Vue的组件创建等等..
猜测是不是瀑布流里的组件是不是太多了,看了下代码好几个按钮点击后都是Popover,和Dialog。在注释掉了一些组件之后明显是快了不少!精简到到不能再精简了还是得花上1.28s。
最后只剩下瀑布流组件vue-waterfall2了!
试着不用瀑布流只是单纯的循环输出只要570ms即可,也就是说瀑布流组件花了有大概710ms。
优化瀑布流组件,换成传统瀑布流后计算位置的方式后、整个位置计算大概耗时只要不到100ms左右。加上组件渲染的时间500ms + 200ms重设前浏览器的dom渲染+ 100ms 位置重设,一起一共大概只要800ms
经过以上轮番优化后整个渲染明显要流畅许多,基本上loading状态消失后内容很快就能展示出来了。渲染速度比起最初的3.xs整整提升了差不多快5倍
后续优化建议:
把每个卡片内几个按钮的Popover,Dialog变成整个列表只有一个组件。
总结
- 列表内如果含有大量内容块应避免过多的Popover,Dialog组件
- 没事多关注组件的性能,时时刻刻关注性能指标,多考虑性能差的电脑
- 动画虽好,但是用的不好就是性能杀手。性能不好的电脑分分钟“Tab未响应”
- 在使用上尽量避免在一个页面内几处动画同时运行。
- 不可视区域内不应该有动画
来源:
- https://zhuanlan.zhihu.com/p/32133614
- https://hospodarets.com/chrome-devtools-performance-monitor
- https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution?hl=zh-cn
- https://stackoverflow.com/questions/8910396/chrome-timeline-how-can-i-determine-the-cause-of-a-recalculate-style-log-ent