一般的性能优化可以通过Chrome的Lighthouse和Performance这两个工具面板指示来进行调整。
Lighthouse
Lighthouse的性能评分会有波动,会受到网络状况、插件等影响(所以建议用无痕模式)。
Lighthouse的10版本的Performance有5个维度的评分,性能得分是各项指标得分加权平均值,先了解这5个维度的评分标准和影响因素。
权重
维度 | 权重 |
---|---|
FCP(First Contentful Paint) | 10% |
SI(Speed Index) | 10% |
LCP(Largest Contentful Paint) | 25% |
TBT(Total Blocking Time) | 30% |
CLS(Cumulative Layout Shift) | 25% |
FCP
FCP是用户首次导航到相应网页到该网页的任何部分呈现在屏幕上所用的时间,也就是呈现第一个内容元素的时间。好的 FCP 值为 1.8 秒或更短。不良值超过 3.0 秒。权重10%。
SI
速度指数衡量在网页加载期间内容直观地显示的速度。它要求的是页面的渲染过程应该是渐进的,内容一点点出现,而不是开始一段时间一直是空白,然后全部内容一下出现。这个指标跟页面渲染时间和渲染方式有关,如果页面渲染时间很短,页面一下就出来了,那它的得分也会很高。0~3.4s为快速,5.8s及以上为慢,中间的为中等。权重10%
LCP
LCP是视口中可见最大图片或文本块的呈现时间(相对于用户首次导航到相应网页的时间)(通过录制页面 Performance 可以看到最大的内容元素是什么)。一般用网页加载的第75个百分位(P75)代表大多数用户情况(最好按照移动设备和桌面设备细分 )。 合适的 LCP 值为 2.5 秒或更短。
TBT
TBT衡量主线程处于阻塞足够长的时间以防止输入响应所用的总时长。如果任务的时间足够长(超过 50 毫秒),用户很可能会注意到延迟并认为网页运行缓慢或卡顿。
CLS
CLS 衡量的是网页生命周期内发生的每次意外布局偏移的最大布局偏移得分。良好的 CLS 值不超过 0.1。不良值大于 0.25。
根据Lighthouse的指示可以发现大部分的性能问提。
实战调整案例
可以看到页面展示的性能情况,问题还是比较多的。
CLS实战调整
针对CLS维度来看,提示Footer的部分局有发生偏移。看了一下代码,Footer默认直接渲染,上方的模块依赖接口请求返回后进行进行渲染。
处理逻辑,最开始默认不展示Footer,等接口有数据返回时再渲染Footer。
处理之后CLS的数据为0.001🎉
LCP调整
这里可以看到页面的最大内容绘制时间过长,点击看四个阶段的不同时间差异。
Render delay占据89%,这个时候就要看哪些影响了渲染(可以根据后续的Performance工具进一步分析)。
Performance
Performance可以进行录制运行时性能,如下图录制主要有三大块,具体各个模块的可以看参考文档。
FP==>FCP==>LCP ,这三个是按照这个顺序来的,DCL跟L需要根据实际场景分析才知道。
查看modules文件(1.56MB,占据55.64%)比较影响,去通过vite的analyse分析打包。
lodash这里有些异常,查看代码,去除了异常的引用,得到下图。
这里lodash、howler、xgplayer,这些引用的第三方都可以单独拆包出去,拆包之后,modules文件490.45KB,占21.48%。
一系列调整后的运行性能结果如下图所示,运行性能的LCP从最初的1123ms到466ms。
其他
- 可以通过Main、Timing、JS Heap等分项指标来具体分析代码问题,如Task过长、内存泄露等等,此处不具体分析,可以查看参考文档~
- 提升LCP时,CSR对LCP有直接影响,可以考虑SSR~
参考文档