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

来源：