内容简介:这篇文章将介绍下实际使用performance对页面进行优化的过程。总的来说,chrome performance工具让我们更方便的发现在代码运行过程中的问题在哪里,便于对一些可能注意不到的问题进行定位、分析和优化。首先,我们对进入整个详情页进行分析,整个页面的结构大致如下,主要包含三个部分:基本信息,可视化图和时间轴。时间轴内部包含时间轴的详情信息,包括表格和几种类型的可视化图等,内部比较重。如图所示:
这篇文章将介绍下实际使用performance对页面进行优化的过程。总的来说,chrome performance工具让我们更方便的发现在代码运行过程中的问题在哪里,便于对一些可能注意不到的问题进行定位、分析和优化。
渲染优化
首先,我们对进入整个详情页进行分析,整个页面的结构大致如下,主要包含三个部分:基本信息,可视化图和时间轴。时间轴内部包含时间轴的详情信息,包括表格和几种类型的可视化图等,内部比较重。如图所示:
我们点击录制,查看进入页面的性能图:
优化点1
可以看到,渲染当前页面的耗时将近1.5s,我们看看到底是哪里出现了问题。对渲染部分进行放大,我们发现在渲染时间轴的过程中,大部分时间耗费在了每个时间节点详情内容的展示上面,但是默认状态下,他们是进行隐藏的。也就是说,我们进行了N个节点的不必要的渲染,只需把他们干掉就好了。
查看代码,发现是以下位置导致的,我们进行了一个展开盒子的封装,类似这样:
<Box data={data} border collapse loading={loading}> <AlertDetail/> </Box>
在非展开状态下,我们依然对内容进行了渲染,只是使用样式进行了隐藏,但是这样React仍然会进行虚拟dom的渲染和计算,在这里我们对其进行改造,让其只在展开时进行渲染,并尽量缓存渲染的结果。修改完成后,我们会发现,Scripting由之前的880+ms变成了670ms减少了200ms左右:
优化点2
我们继续看,会发现页面初始化时,详情部分会有大量的Evaluate Script耗时,主要是耗费在告警详情右侧的分类及各分类下的可视图及详情引起的。
我们可能会想,这里在初始化时并没有进行渲染,为什么仍然会耗费时长进行计算呢?继续追查我发现原因在这里:
在整个详情组件中,我们对包括http,tcp等所有类型的组件进行了引用,然后根据其类型进行组件的匹配,在各个组件中可能包含了每个类型对应的定义、分类和计算等等等等,不仅增加了加载时间,更延长了初始化时间,显然我们这么做是不对的。
在此,我们可以使用 懒加载 方式对其进行优化,仅展示其对应类型的图,避免了不必要的资源浪费和计算时间。
修改之后,我们再次进行性能测试,发现在进入页面时,详情组件的耗费时长由260ms变为不到2ms:
而Scripting由之前的670+ms变成了415ms减少了250ms左右:
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Hybrid 实战:如何完整下载一个 wap 页面
- flutter实战6:TAB页面切换免重绘
- Spark综合使用及电商案例页面转化率统计分析实战-Spark商业应用实战
- 「小程序JAVA实战」小程序的横向视频和页面拦截(58)
- Python3网络爬虫实战---37、动态渲染页面抓取:Selenium
- 「小程序JAVA实战」小程序页面的上拉下拉刷新(49)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。