可以明显感觉到搜索结果页即使接口速度在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未响应”
  • 在使用上尽量避免在一个页面内几处动画同时运行。
  • 不可视区域内不应该有动画

来源: