Lighthouse 是一个误导性的性能工具吗？

Google 将 Lighthouse 称为“一款用于提升网页质量的开源自动化工具”。它本身并非性能工具，但其突出特点是能够提供网页性能反馈。在 Lighthouse 中获得移动端最高性能分数是一项巨大的挑战。如果您曾尝试在 Lighthouse 中获得最高分数——这可能会让您怀疑自己、怀疑这款工具，甚至两者兼而有之！让我们探索 Lighthouse，看看其中的原因。

Lighthouse 是否具有误导性，或者是一种误解？

问题 1 - 评分标准不是线性的

您可能认为性能得分是线性的，即100 分比 90 分好 10%，但事实并非如此。实际上，得分遵循曲线分布，以下是“交互时间”（TTI）指标的得分曲线：

谷歌在其文档中讨论如何对分数进行颜色编码时提到了这一点：

为了提供良好的用户体验，网站应努力获得良好的评分（90-100）。“完美”的 100 分极难达到，且并非指望。例如，将评分从 99 分提升到 100 分所需的指标改进量与将评分从 90 分提升到 94 分所需的指标改进量大致相同。

绩效得分计算的这一特点意味着，你为提高得分所付出的努力将根据你在曲线上的位置而有所不同。打个比方，这就像一个跑步者在比赛中始终付出同样的努力：

• 下坡跑：跑步者会跑得更快；
• 在平地上：跑步者将按照正常速度跑步；
• 上坡：跑步者会跑得更慢。

也许，你没想到这个从零到百的评分系统会有这样的结果。我没想到！毕竟“百分比”这个词的意思是“百分之一”。如果选择不同的范围或分布，这种误解或许可以减轻。或许，如果把分数显示为每个指标曲线上的一个点，就能减少一些人的困惑？

您可以深入了解评分算法的细节，以更深入地理解它。

问题 2 - 分数可能相差很大

如果您在同一网络上的同一台计算机在同一个网站上多次运行 Lighthouse，您将得到不同的结果。乍一看，这感觉很奇怪。我重复了同样的事情，却得到了不同的结果？这是 bug 还是扭曲的现实？

谷歌对分数变化的评价如下：

您的整体性能得分和指标值的波动很大程度上并非由 Lighthouse 造成。性能得分波动通常是由于基础条件的变化造成的。常见问题包括：

• A/B 测试或所投放广告的更改
• 互联网流量路由变化
• 在不同的设备上进行测试，例如高性能台式机和低性能笔记本电脑
• 注入 JavaScript 并添加/修改网络请求的浏览器扩展
• 防病毒软件

这不是灯塔的功劳吗？🤔 我们这是在试图束缚闪电吗？😏

它有多大的变化？

在不同的硬件上进行测试。差异可能非常显著。Zach Leatherman 在《欺骗的艺术，灯塔评分版》一文中讨论了这一点——在 MacBook（2012 年）和 MacBook Air（M1，2020 年）上运行 Lighthouse 测试，结果相差 30 分！这差距可真大。

看来，您可以通过Google 的网页用户体验工具PageSpeed Insights (PSI)运行 Lighthouse 来减轻硬件的影响。我猜这会持续影响一组特定的服务器。

如果您想了解细节，Google 会提供这些差异的技术因素的完整列表。

Lighthouse 的 GitHub 代码库中建议，为了减少差异，应该“多次运行 Lighthouse，并在得出影响性能的变更结论之前，留意差异”。为什么不在 Lighthouse 中内置这种行为来减少差异呢？

WebPageTest是一款与之竞争的 Web 性能工具，其默认行为是基于 3 次运行给出一个性能得分的中位数。WebPageTest 团队一直对 Lighthouse 结果的一致性持批评态度。虽然可以通过 WebPageTest 运行 Lighthouse，但他们声称 Lighthouse 可以提供更一致的结果，因为他们提供了更一致的测试环境。

虽然测试之间可能会存在一些差异，但通过为所有 Lighthouse 运行提供一致的测试环境，WebPageTest 有助于最大限度地减少这种差异，并提供一个现实且可重复的比较点。

他们指出，Lighthouse 使用模拟节流技术是可以缓解的变异源之一。

默认情况下，Lighthouse 使用模拟节流：测试在没有节流的情况下运行，然后 Lighthouse 根据不受节流的结果模拟节流负载的情况。

另一方面，WebPageTest 对所有测试（包括通过 WebPageTest 运行的 Lighthouse 测试）都使用数据包级限流。由于数据包级限流能够在数据包级别实现网络整形，因此它能够更精确地模拟真实的网络状况（如果您想深入了解这个话题， Lighthouse团队有一篇关于限流准确性的精彩研究）。

问题 3 - 绝大多数网站排名不佳

让我们回到2020年，当时谷歌对其性能评级进行了重大调整——他们推出了核心网络指标 (Core Web Vitals)。我想讨论这个时间段，因为这是性能指标集（5个指标）和核心网络指标（3个指标）之间最后一个具有清晰可比数据的点。核心网络指标是性能指标集的一个子集。

为了简化操作，我们引入了核心网络指标。谷歌是这样说的：

网站所有者无需成为性能专家，即可了解其为用户提供的体验质量。Web Vitals 计划旨在简化流程，帮助网站专注于最重要的指标——核心 Web Vitals。

根据《Web Almanac 2020》在其 Web 性能评估报告中显示，Lighthouse 报告称，0.7% 的网站移动性能得分为 100，5.7 % 的网站处于良好水平（90-100）。Web 性能真的那么糟糕吗？还是标准太高了？

我试图了解 Google 如何选择好的类别阈值，这是他们最清晰的解释，特别是针对最大内容绘制 (LCP) 指标：

根据真实网站数据，表现最佳的网站在大约 1,220 毫秒内渲染 LCP，因此该指标值映射到 99 分。

更深入地讲，Lighthouse 评分曲线模型使用 HTTPArchive 数据确定两个控制点，然后设定对数正态曲线的形状。HTTPArchive 数据的第 25 个百分位数得分为 50（中值控制点），第 8 个百分位数得分为 90（良好/绿色控制点）。

这是否意味着前 8% 的数据代表 90 分及以上？说实话，我不明白他们的解释！😕 虽然根据我之前对 Web Almanac 的分析，这听起来差不多。

Barry Pollard 在他的文章《网络上的 Lighthouse 评分是什么样的？》中通过查询 HTTP Archive 的数据对网络上的 Lighthouse 评分进行了一些分析，结果类似。关于顶级评分，他说道：

[...] 90％ 的网站在性能方面的得分为 80 或更低，或者换句话说，只有 10％ 的网站在性能类别中的得分高于 80。

总是只有一小部分网站能够获得“良好”的性能评分，因为只有前 8% 的网站才有资格进入这一类别。如果数百万个网站的性能在一夜之间得到显著提升，那么标准就会提高，要想进入“良好”类别，就需要付出更多努力。

根据相同数据（可通过 HTTP 存档获取的 Chrome 用户体验报告数据），在大致相同的时间段内（2020 年 8 月至 10 月），22.3% 的页面通过了所有 3 个核心 Web 重要指标，并获得了“良好”的评分。通过核心 Web 重要指标的网站数量，比在 Lighthouse 中获得“良好”性能评分的网站数量还要多。

随后几年，性能评分体系不断完善。Lighthouse 的最新版本是 10。自版本 6 以来，评分体系中仍使用了 5 个相同的指标，阈值和权重也进行了调整。最近引入了一个名为“交互到下一次绘制”（INP）的新指标，并将于 2024 年 3 月取代“首次输入延迟”（FID），成为核心 Web 重要指标。

我觉得奇怪的是，Chrome 开发者工具中的 Lighthouse根本没有提到核心 Web 指标。它仍然给出了 5 个指标的性能分数。那么，为什么要给用户提供更复杂、更具挑​​战性的指标呢？

为了定义阈值，谷歌解释了与人类感知阈值和相关人机交互研究相关的阈值背后的科学原理。阈值基于我们对事物的感知方式，但在网络上如何实现呢？谷歌在其关于定义阈值的文章中说道：

为了确认阈值是否可行，我们要求目前至少有 10% 的来源达到“良好”阈值。此外，为了确保优化良好的网站不会因现场数据的差异而被错误分类，我们还会验证优化良好的内容是否始终达到“良好”阈值。

因此，综合以上所有数据，谷歌的最低要求是，10% 的网站被归类为满足核心网站指标的“良好”性能阈值。这听起来核心网站指标比整体性能指标要宽松一些，但仍然非常具有挑战性。

我们可以在 HTTPArchive 上看到过去 3 年多来的 Core Web Vitals 数据，通过移动 Core Web Vitals 的来源百分比从 22.6% 增加到了 40.7%。

我希望看到整体性能得分也用同样的图表。我猜应该会低很多。

问题 4 - 它是现场数据还是实验室数据？

了解实验室数据和现场数据之间的区别非常重要。Lighthouse是一种基于实验室的工具，也称为合成工具。

实验室数据是在具有预定义设备和网络设置的受控环境中收集的。它的主要用途是调试性能问题，因为它提供了可重现的测试和调试环境。缺点是实验室数据无法很好地捕捉现实世界中的瓶颈。

现场数据是从用户在实际使用环境中体验到的真实页面加载情况中收集的性能数据。收集现场数据的工具通常被称为真实用户监控 (RUM) 工具。现场数据能够捕捉真实的用户体验。PageSpeed Insights 使用Chrome 用户体验报告 (CrUX) 数据集来增强 Lighthouse 提供的相同指标的实验室数据。但是，您的页面或来源可能不在数据集中，因为它无法公开发现，或者访问者数量不足以创建具有统计意义的数据集。

这种二分法的一个很好的例子是查看web.dev上的 PSI 报告，这是 Google 的博客，里面有很多关于 Lighthouse 的信息。你可以在这个 URL 上看到我运行的测试结果：https://pagespeed.web.dev/analysis/https-web-dev/hp4cd34d4i ?form_factor=mobile 。

Lighthouse 报告的性能得分为 96，但却未通过核心 Web 指标测试！乍一看，这看起来像是一个错误！这是怎么回事？

这是因为 PSI 报告的核心 Web 指标的 LCP 指标和整体性能得分的数据不同（请参见下方截图中的黄色高亮部分）！数据之所以不同，是因为 PSI 在第一部分中使用了 CrUX 数据集中的现场数据作为核心 Web 指标（如果可用），而在第二部分中使用了实验室数据作为性能得分。

你可能会忽略这一点！一开始，同时使用两个不同的数据集来设置两个不同的指标集让我感到困惑。另外，如果你关注的是核心网络指标，那么根据测试方法，有两套指标集可供选择：

• Lighthouse 中的实验室测试：最大内容绘制 (LCP)、累积布局偏移 (CLS)、总阻塞时间 (TBT)。
• PageSpeed Insights 中的现场测试：最大内容绘制 (LCP)、累积布局偏移 (CLS)、首次输入延迟 (FID)。

此前，PSI 报告会更明确地说明结果使用的是现场数据还是实验室数据。以下是几年前 PSI 报告的示例截图：

我认为 UI 的更新看起来更漂亮，但不太明显。

您可以在web.dev 的《如何思考速度工具》中阅读有关如何思考工具的更多信息。

问题 5 — 移动设备还是桌面设备？

当人们讨论和比较 Lighthouse 评分时，他们通常会截屏记录。用户界面上没有显示结果是针对移动设备还是桌面设备的。移动端性能的门槛更高。这很容易导致错误和误传。

曾经有人讨论过添加视觉指示器以使模式更加明显，但它还没有进入 Chrome devtools！

问题 6 - 人们不可避免地追求近乎完美的成绩

人们不可避免地会追求近乎完美的性能得分。人们为自己的工作感到自豪，并乐于指着自己制作的东西说“看看它的性能”。如果你构建了一个门槛很高的工具，那么对于某些类型的网站和 Web 应用来说，获得最高得分将变得遥不可及。像亚马逊这样要求严格的 Web 商店、像 Google Docs 这样的 Web 应用以及个人网站之间并没有什么区别。

为了强调这种情况， Lighthouse GithHub repo 上有一个讨论主题“在移动设备上获得 100 分的说明” ：

我曾经用 Lighthouse 监控过一个网站的性能。但是，在移动端很难拿到 100 分。我只能用一个只有静态文本、没有 CSS 和 JavaScript 的网站来跑分。

我不确定灯塔团队是否认为网站只包含静态文本对于当今的现代网站来说是流行的。

当然，PWA 今天还不是标准，即使是 PWA，我们也必须加载“完整状态”模式。

不久前我也对此感到惊讶。我重建个人网站时，从最简单的主页开始。我没有图片，样式表也很小，我记得我用了三种网络字体。结果移动端评分并不“好”！我不得不优化这些资源，才能达到90分以上。

另一个原因是，当涉及到数字时，它会导致竞争因素。框架和库倾向于利用这一点来提升其产品的速度和性能。Eleventy 有一个排行榜，它使用一个基于 Lighthouse 的插件speedlify来对网站进行排名。

Lighthouse 适合用这种方式比较网站吗？🤨

最后的想法

衡量 Web 性能并非易事。我们并非以统一的方式打造同质的 Web 产品。因此，定义 Web 上的良好性能至关重要。Google 一直积极利用其指标和工具来定义良好的性能，并在这方面拥有很大的发言权。

Google 将 Lighthouse 称为“一款用于提升网页质量的开源自动化工具”。它在审核过程中会检查网页的几个不同方面，例如：性能、SEO 和可访问性。它本身并不是一个性能审核工具，但它在该领域占有重要地位，因为 Google 开发了它，并将其集成到 Chrome 浏览器中，并宣布核心 Web Vitals 指标是其搜索排名的一个因素！

Lighthouse 主要是一款基于实验室的工具，用于性能调试。它有一些不太明显的特性。评分计算非常复杂，结果差异很大，而且很难获得“良好”的移动性能评分。正如我在本文中所述，部分原因可以归因于需要充分理解 Web 性能和 Lighthouse，但 Lighthouse 在某些方面具有误导性。

谷歌表示，要达到 100 分的完美移动性能分数“极其困难”。他们对性能分类的方法远比“胡萝卜”要严格得多。2020 年末，根据 Lighthouse 的分类，只有不到 6% 的 Web 源被认为达到了“良好”的性能，而 22.3% 的 Web 源通过了核心 Web 重要指标 (Core Web Vital)。核心 Web 重要指标是一套更为宽松的指标。

核心 Web 指标 (Core Web Vitals) 让更多企业开始关注 Web 性能。正如Web Almanac 在 2022 年性能评估中所述：

谷歌决定将 CWV（核心网站重要指标）纳入搜索排名，这让性能成为许多公司（尤其是在 SEO 行业）发展路线图的首要任务。个人网站所有者无疑正在努力提升自身性能，并在过去的一年中为 CWV 的改进做出了重要贡献，尽管这些个人的努力在如此规模的网站上很难被发现。

在撰写本文时，通过移动核心网络生命力测试的来源百分比为 40.7%。

Web Vitals 计划的目标是简化性能概览，但我认为它做得并不好。它缺乏清晰度和重点。你的性能得分仍然基于完整的指标集。完整的指标集显示在 Chrome 的开发者工具中，许多人第一次接触 Lighthouse 就是在这里。

CWV 指标实际上尚未得到全面采用。PSI 首先显示 CWV 指标，但旁边还有另外 3 个指标。它无法向用户清晰地传达信息——您应该通过 CWV 测试，还是获得“良好”的性能分数，还是两者兼而有之？对于您的特定类型的应用程序来说，实际的分数是多少？

分数的波动性意味着 Lighthouse 存在一些问题。通常来说，它不是一个非常可靠的性能调试工具。由于分数波动性在本地运行时会受到机器性能的影响，因此在 Chrome 的开发者工具中运行 Lighthouse 可能不是一个好主意。最好通过 WebPageTest 使用 Lighthouse，因为它可以更好地缓解波动性，或者使用其他工具来调试性能。

我建议主要使用 Lighthouse 来了解 Google 如何对你的网站进行分类。Lighthouse审核提供的机会可以为你提供提升网站性能的粗略指导，但切勿盲目相信。现场数据可以让你更真实地了解用户体验，你应该利用它来了解网站的性能。

您可以订阅我的 RSS 源以获取我的最新文章。