优化商品详情页面的互动性，以便将 Lighthouse 中的最大潜在 FID 降低 90%，并将 Chrome 用户体验报告中的 FID 降低 9%。
Mercado Libre 是拉丁美洲最大的电子商务和支付生态系统。它覆盖 18 个国家/地区，在巴西、墨西哥和阿根廷（根据唯一身份访问者和网页浏览量判断）是市场领导者。
很长时间以来，网站性能一直是该公司的关注重点，但最近他们组建了一支团队来监控性能，并在网站的不同部分应用优化措施。
本文总结了 Mercado Libre 前端架构团队的 Guille Paz、Pablo Carminatti 和 Oleh Burkhay 为优化核心网页指标之一 - First Input Delay (FID) 及其实验室代理 Total Blocking Time (TBT) 所完成的工作。
90%
Lighthouse 最高潜在 FID 降幅
9%
在 CrUX 中，将 FID 视为“快速”的用户增多
耗时较长的任务、First Input Delay 和 Total Blocking Time
运行成本高昂的 JavaScript 代码可能会导致长时间运行的任务，即在浏览器的主线程中运行超过 50 毫秒的任务。
FID（First Input Delay）用于衡量从用户首次与网页互动（例如，点击某个链接）到浏览器实际能够开始处理事件处理脚本以响应此次互动之间的时间。执行成本高昂的 JavaScript 代码的网站很可能会有多项耗时较长的任务，最终会对 FID 产生负面影响。
为了提供良好的用户体验，网站应努力将 First Input Delay 控制在 100 毫秒以内：
虽然 Mercado Libre 的网站在大多数版块中都表现良好，但他们在 Chrome 用户体验报告中发现商品详情页面的 FID 不佳。根据这些信息，他们决定将工作重点放在改善网站中商品页面的交互性上。
这类页面允许用户执行复杂的互动，因此其目标是实现互动优化，而不会干扰有价值的功能。
衡量商品详情页面的互动性
FID 需要真实用户，因此无法在实验室中衡量。但是，Total Blocking Time (TBT) 指标可由实验室衡量得出，与实际应用的 FID 非常相关，并且还能捕获影响互动的问题。
例如，在以下跟踪记录中，虽然在主线程上运行任务所花费的总时间是 560 毫秒，但只有 345 毫秒的时间被视为总阻塞时间（每个任务中超过 50 毫秒的部分的总和）：
在实验室中，Mercado Libre 将 TBT 作为替代指标，用于衡量和改进商品详情页面在现实世界中的互动性。
以下是他们采取的常规方法：
- 使用 WebPageTest 来准确确定哪些脚本在真实设备上使主线程保持忙碌。
- 使用 Lighthouse 确定最大潜在 First Input Delay (Max Potential FID) 中更改的影响。
使用 WebPageTest 直观呈现较长的任务
WebPageTest (WPT) 是一种 Web 性能工具，可让您在全球不同位置的真实设备上运行测试。
Mercado Libre 使用 WPT 选择与真实用户类似的设备类型和位置，以重现用户的体验。具体来说，他们选择了 Moto 4G 设备和弗吉尼亚州杜勒斯，因为他们想要大致估算墨西哥 Mercado Libre 用户的体验。通过观察 WPT 的主线程视图，Mercado Libre 发现有几个连续的长任务阻塞主线程 2 秒：
在分析相应的广告瀑布流后，他们发现这两秒中有相当一部分来自于其分析模块。该应用的主软件包较大 (950KB)，需要很长时间来解析、编译和执行。
使用 Lighthouse 确定最大潜在 FID
Lighthouse 不允许您在不同的设备和位置之间进行选择，但它是一款非常实用的工具，可用于诊断网站并获得性能建议。
在商品详情页面上运行 Lighthouse 时，Mercado Libre 发现最大潜在 FID 是唯一标记为红色的指标，值为 1710ms。
基于这一假设，Mercado Libre 设定了一个目标，即在 Lighthouse 和 WebPageTest 等实验室工具中提高其最大潜在 FID 得分，并假设这些改进会影响其真实用户，因此会出现在 Chrome 用户体验报告等真实用户监控工具中。
优化耗时较长的任务
首次迭代
根据主线程轨迹，Mercado Libre 设定了优化两个运行昂贵代码的模块的目标。
他们开始优化内部跟踪模块的效果。此模块包含一项占用大量 CPU 的任务，而该任务对模块正常工作并不重要，因此可以安全移除。此举使整个网站的 JavaScript 数量减少了 2%。
之后，他们开始着手改善软件包的总体大小：
Mercado Libre 使用 webpack-bundle-analyzer 来检测优化机会：
- 最初，他们需要完整的 Lodash 模块。取而代之的是 per-method require，以便仅加载 Lodash 的子集，而不是整个库，并且与 lodash-webpack-plugin 结合使用可进一步缩减 Lodash。
他们还应用了以下 Babel 优化：
- 使用 @babel/plugin-transform-runtime 在整个代码中重复使用 Babel 的帮助程序，并大幅缩减软件包的大小。
- 在构建时使用 babel-plugin-search-and-replace 替换令牌，以移除主软件包中的大型配置文件。
- 添加 babel-plugin-transform-react-remove-prop-types，通过移除属性类型节省一些额外的字节。
通过这些优化，软件包大小缩减了约 16%。
衡量影响
这些变更将 Mercado Libre 的连续长时间任务从两秒缩短为一秒：
Lighthouse 的潜在 First Input Delay 上限减少了 57%：
第二次迭代
该团队继续深入研究耗时较长的任务，以寻找后续改进。
根据这些信息，他们决定实施以下更改：
- 继续缩减主软件包的大小，以优化编译和解析时间（例如，移除不同模块中的重复依赖项）。
- 在组件级别应用代码拆分，将 JavaScript 拆分为较小的块，并允许更智能地加载不同组件。
- 推迟组件水合，以便以更智能的方式使用主线程。这种方法通常称为“部分水合”。
衡量影响
生成的 WebPageTest 跟踪记录显示了更小的 JS 执行块：
此外，Lighthouse 的最大潜在 FID 时间又减少了 60%：
直观呈现真实用户的进度
虽然 WebPageTest 和 Lighthouse 等实验室测试工具非常适合在开发期间对解决方案进行迭代，但真正的目标是改善真实用户的体验。
Chrome 用户体验报告提供了用户体验指标，以便反映实际 Chrome 用户在网络上对热门目的地的体验。您可以通过在 BigQuery 中运行查询、PageSpeedInsights 或 CrUX API 来获取报告中的数据。
CrUX 信息中心是直观呈现核心指标进度的一种简单方式：
后续步骤
网页性能从来都不是完成的任务，Mercado Libre 了解这些优化可为其用户带来的价值。在继续在整个网站上应用多项优化（包括在商品详情页面进行预提取、图片优化等）的同时，他们继续对商品详情页面进行改进，以缩短总阻止时间 (TBT) 和代理 FID 等等。这些优化包括：
- 迭代代码拆分解决方案。
- 改进第三方脚本的执行方式。
- 继续改进捆绑器级别的资源捆绑功能 (webpack)。
Mercado Libre 能够全面了解性能，因此在继续优化网站的互动性的同时，他们也开始评估当前核心网页指标（即 LCP (Largest Contentful Paint) 和 CLS (Cumulative Layout Shift)）的改进机会。