一次 Chrome Timeline 调优记录

其实这是一篇 Chrome Dev Tool 中 Timeline 调性能的笔记。

背景

采购商城是阿里集团采购需求的响应门户。体验+平台是信息平台用户体验部为监控各个业务线的主要产品前端指标所做的体验监控平台,可展示多种性能维度,比如错误页面占有率及加载时间平均值等。

几周前,我悄悄把采购商城接入了体验+平台,一开始的数据特别难看,采购商城的平均页面加载时间近5秒(当然下面那幅图是优化之后的),于是我花了近一天的时间决心解决这个难看数据。

image.png

优化步骤

1)明确慢的点在哪

经过内部平台分析,发现采购商城的首页是拉低采购商城平均加载速度的元凶,在12月6日之前,首页的完全加载时间平均超过5秒以上。

完全加载时间计算方法是:window.performance.timing.responseStart - window.performance.timing. loadEventStart,对应的时间点,如下图所示:

image.png

在知道了首页是主要因素之后,目标就明确了,那就是先把这个首页的性能问题解决。

2)图片优化

这个就不细说了,就是把首页展示的大图变小图,图片加了 lazyload 的能力,但优化下来的效果不明显,页面完全加载时间依旧是徘徊在 5S 左右。

3)使用 Timeline 工具进行详细定位

本文的重点来了。

3.1)分析页面加载的时间及各部分占比

image.png

如上图,使用 Performance 工具,点击工具栏的刷新(注意不是页面刷新)执行一次页面载入,发现在前4S中有,有近3S是在跑 JS,这 3S 是会计算进页面完全加载的时间去的。

image.png

紧接着,点击 Event Log 选项,仅选中 Scripting,然后将 Total Time 从大到小排列,发现有多个 XHR 事件占用了大量时间。于是立刻怀疑是后端接口时间长,但经过验证发现不是这个原因。那到底是什么原因导致慢呢?

image.png

最终经过定位,发现 React 的 setState 是最耗性能的地方。

3.2)解决最耗性能的核心痛点

至此,已经发现了核心点,就是首页加载时多个 XHR 的响应时间占用了大量时间,而响应中 setState 是最耗时的。

于是开始筛查我的首页代码,最终得到的结论与性能分析一致,我在首页加载的时候会发送4个 ajax 请求,然后执行 6 次 datapool.setValue 的 API,经过跟乐高团队的讨论,发现这个 setValue API 的确是消耗性能的,乐高团队建议我修改成一次 setValue,实际上就是使用乐高提供的数据源面板能力,将数据请求整合起来,一次性 setValue。

3.3)检验效果

经过程序改良,页面的加载速度其实从肉眼就可以辨别出来了,但肉眼不准确,得拿数据说话。

image.png

看上图,在同样一次页面加载的过程中,Scripting 变成了1.7S,把代码测试发布之后,得到的结果也是肯定的。

image.png

从上图可以看出,在12月5日晚发布程序之后,12月6日加载时间明显降低30%以上。

总结

在前端性能优化领域,首先基于数据抓关键页面,关键页面要善于使用 Performance 工具找元凶,在本次性能优化实践之后,其实还有很多其他的点也可以优化,不过我们应该善于抓核心痛点,将最主要的部分先解决往往会有事半功倍的效果。