性能治理之页面LongTask优化

前言

在现代 Web 应用中，页面性能直接影响用户体验和业务发展。我们近期对列表页进行了一次全面的性能优化，旨在提升用户访问效率，提升用户满意度。

接下来，将为大家详细分享这次优化的过程、方法和成果。

一、优化目标与用户分析

我们将优化目标聚焦于核心列表页，通过BLM健康平台（内部访问统计平台）筛选出高流量且秒开率低的页面作为重点优化对象。同时，利用日志进行深度剖析，明确优化的用户范围。

初次进入用户：占比18.41%，秒开率接近于0；
二次进入用户：占比81.87%，秒开率27.85%。

基于这一数据，我们确定二次进入用户中的未秒开用户是本次优化的主要目标群体，占比约为58.85%,这一决策基于两个关键考量：

初次进入用户受网络环境和首次加载影响较大，优化空间有限；
二次进入用户占比高且已有部分秒开，优化潜力更大。

二、性能优化尝试

qiankun 架构下某核心列表加载流程简图

在 qiankun 架构下，列表的加载流程具有一定的复杂性。我们针对这一流程，分阶段展开，具体内容如下：

第一阶段：静态资源优化（DLC）

首先从静态资源入手，对相关文件和模块进行调整，具体优化内容及前后指标对比如下：

关键收获：非关键资源的延迟加载或移除可以显著降低TBT（Total Blocking Time 总阻塞时间）。

第二阶段：DLC到FCP

本次优化暂不考虑

第三阶段：主应用FCP到LCP优化

针对主应用的关键渲染路径，重点优化了：

javascript 复制代码

// 修改前：筛选项全部渲染
renderAllFilters() {
  // 渲染所有筛选项（包括隐藏内容）
}

// 修改后：按需渲染
renderVisibleFiltersOnly() {
  // 只渲染可见的筛选项
}

优化效果对比：

第四阶段：长任务分解

核心优化方案

基于以上分析，我们总结出以下优化建议（按收益排序）：

筛选项懒加载：TTI最多减少642ms；
大数据枚举虚拟化：司机标签TTI减少594ms，城市组件减少179ms；
接口调用顺序调整：TTI减少355ms；
表格组件优化：TTI减少430ms；
缓存逻辑优化：TTI减少170ms；
CSS合包处理：TTI减少60ms；

优化效果验证

通过A/B测试和监控平台数据对比：

优化前（02.12-02.18）：秒开率17.15%；
优化后（02.28-03.04）：秒开率31.92%；
提升幅度：14.77个百分点；

三、分析方法沉淀

目标设定阶段

通过BLM健康平台确定需优化页面

高流量页面优先
秒开率低页面优先

通过性能埋点日志确定可优化范围

使用 Node 脚本将一段时间日志进行分类分析：是否初次进入 / 是否存存在缓存。

确定可优化用户范围，若用户范围过小或无法达成，可放弃优化，转向其他页面。

问题定位方法

我们主要使用以下工具进行性能分析：

关键指标解释：

FCP（First Contentful Paint）：首次内容渲染
LCP（Largest Contentful Paint）：最大内容渲染
TBT（Total Blocking Time）：总阻塞时间（FCP到TTI之间超过50ms的任务部分总和）
TTI（Time to Interactive）：可交互时间

Lighthouse初步诊断：获取整体性能评分和优化建议。

任务分析：通过 Performance insights 的 Main 线程火焰图定位长任务 & 检查接口并行性和响应时间。

Performance深度分析：

使用 Performance 工具打开待优化页面，根据任务分析中找到的阻塞点函数进行搜索定位。在有 map 文件的环境或本地环境中，通过调用栈信息，找到阻塞或长任务对应的代码块。
- LCP 后的任务阻塞一般是由接口返回数据渲染导致，这时可以结合 Network 火焰图找对应关系，明确是那个 API；
- Network 中资源条目的时间包括请求前等待时间以及请求后解析时间，可根据解析时间判断哪个接口数据导致了阻塞；
- 可在函数执行前添加console.profile()，在函数执行后添加console.profileEnd()语句，定向分析该函数对性能的影响（此方法对异步任务的支持有限）。

javascript 复制代码

// 示例：标记关键函数执行
console.profile('filterRender');
renderFilters();
console.profileEnd('filterRender');

主要通过以上三步确定阻塞点并进行分析。若想深入分析阻塞点的具体原因，可在本地环境中使用 Performance 进行分析（可获取具体函数调用栈），或使用 Profiles（在 Memory 标签下）进行分析，以确定哪些函数导致了内存占用的波动等问题。

方案验证（whistle）

安装好 whistle 客户端并配置规则，将需要更改的文件代理到本地进行修改；

本文所得数据均以此方式进行测试

确定修改方案的ROI

根据分析以上分析列出可优化点，并对所有优化方案进行评估计算 ROI，优先选择收益高且优化成本低的优化方案进行优化。

结果验证阶段

对优化方案进行优化开发和测试；
上线后通过健康平台和性能日志进行数据指标验证是否达到预期。

四、经验总结与未来建议

基于本次优化经验，我们提炼出以下通用建议：

1.按需加载原则：

非首屏内容延迟加载；
大数据枚举使用虚拟滚动；

2.关键渲染路径优化：

关键接口尽早调用（created生命周期）；
避免渲染阻塞接口请求；

3.长任务分解：

将超过50ms的任务拆分为小任务；
使用 Web Worker 处理复杂计算；

4.缓存策略：

合理使用内存和 IndexedDB 缓存
避免缓存更新阻塞主线程

5.监控体系：

建立完整的性能监控体系
定期分析用户行为日志

结语

本次优化实践表明，系统化的性能优化需要：

精准的用户行为分析确定优化方向；
科学的工具链进行问题定位；
严谨的ROI评估确定优化优先级；
完善的监控体系验证优化效果。

通过这四步方法论，不仅提升了特定页面的性能，更建立了一套可复用的前端性能优化体系，为后续其他页面的优化提供了宝贵经验。性能优化是一个持续的过程，我们将不断探索和实践，为用户带来更流畅、高效的使用体验。希望本次分享能为大家在页面性能优化方面提供有益的参考和借鉴。

附：

Lighthouse

Lighthouse 是 Google 开发的一款工具，用于分析网络应用和网页，收集现代性能指标并提供对开发人员最佳实践的意见。为 Lighthouse 提供一个需要审查的网址，它将针对此页面运行一连串的测试，然后生成一个有关页面性能的报告。

页面的性能 Performance 评分，包括：

首次内容绘制（FCP First Contentful Paint）；
最大内容渲染时间（LCP largest contentful Paint）衡量感知加载速度；
总阻塞时间 (TBT Total Blocking Time）TBT 衡量的是页面被阻止响应用户输入（例如点击鼠标、点按屏幕或按键盘）的总时长。总和的计算方法是将 First Contentful Paint 和 Time to Interactive 期间所有长任务的阻塞部分相加。任何执行时间超过 50 毫秒的任务都是耗时较长的任务。50 毫秒后的时间是阻塞部分。例如，如果 Lighthouse 检测到一个时长为 70 毫秒的任务，则阻塞部分将为 20 毫秒。
累积布局偏移（CLS Cumulative Layout Shift）衡量视觉稳定性；
速度指标（Speed Index）

Performance

Performance 是 Chrome 提供给我们的开发者工具，用于记录和分析我们的应用在运行时的所有活动。它呈现的数据具有实时性、多维度的特点，可以帮助我们很好地定位性能问题。使用 Performance 工具时，为了规避其它 Chrome 插件对页面的性能影响，我们最好在无痕模式下打开页面。

控制面板 | 开始记录，停止记录和配置记录期间捕获的信息。
概览面板 | 对页面表现（行为）的一个概述。
- FPS | 绿色的柱越高， FPS 值也越高，红色则说明可能出现了卡顿。
- CPU | 表明了哪些事件在消耗 CPU 资源。
- NET | 蓝色代表 HTML 文件，黄色代表 Script 文件，紫色代表 Stylesheets 文件，绿色代表 Media 文件，灰色代表其他资源。
火焰图面板 | 可视化 CPU 堆栈(stack)信息记录。
- 从不同的角度分析框选区域。例如：Network，Frames, Interactions, Main 等。

Performance insights

Performance insights 是 Chrome Chrome DevTools中的自带工具（Chrome102 版本发布），目前还是在Chrome DevTool中启动即可，如下图所示：我们可以模拟cpu，选择4x slowdown，就开始模拟4倍低速 CPU，同理还可以模拟网络应对不同网络的测试需求。 Performance insights 工具最方便的部分是"insights"面板，它位于面板的最右侧。它以垂直时间线的形式按照事件发生的顺序显示事件，如渲染阻塞请求、长任务、布局变化等。点击这些具体事件将导航到"详细信息"选项卡，它给出了关于它的潜在原因和受它影响的元素等的详细信息，在Details中看到影响性能问题的各种因素。想要进一步进行优化,点击该事件就可以查看关于问题的详细描述和具体的优化方案。另外在页面的顶端（绿色框）我们可以方便的看到当前页面DCL，FCP，LCP和TTI这些参数指标

性能监控日志

性能监控日志以 JSON 格式记录了丰富的页面性能数据。我们可以将埋点日志下载到本地，通过 Node 脚本对其进行计算和分析，从而获取所需的数据，如 IndexedDB 缓存平均等待时间、资源加载及解析时间、接口响应后到 TTI 计算结束时间等，也可以通过此方式计算优化某个点的收益等。