Google Lighthouse：道德黑客手册，用于增强用户体验和搜索引擎可见性 (2024)

Google Lighthouse 是游戏化和鼓励开发人员提高网页性能的最有效方法之一。利用 Lighthouse，我们能够根据整体有效性、可访问性、SEO 和 Google 首选的“最佳实践”来评估网页 - 只需按一下按钮即可。

这些测试可用于评估前端框架的默认性能，或展示通过精心重组实现的效率改进。在社交媒体上展示您无可挑剔的 Lighthouse 评级无疑是令人欣慰的。这是一项值得热烈庆祝的令人尊敬的成就。

Lighthouse 激发了我们这些开发人员对性能的讨论，这一简单事实本身就是一项胜利。然而，尽管这个问题的重要性不言而喻，但 Web 性能要复杂得多。在本文中，我们将探讨 Google Lighthouse 性能评估背后的方法，并利用这些知识，努力操纵这些结果，以利于我们。 一切都是为了享受和探索 – 最终，Lighthouse 可以作为诊断性能问题的可靠但粗略的指南。让我们玩一玩它，看看我们能在多大程度上超越 Lighthouse，从而给出比我们合理获得的分数更高的分数。

但在此之前，让我们先深入研究数据。

现场数据至关重要

本地性能评估可以提供有关您的网站性能是否在朝着积极的方向发展的宝贵见解，但它们并不能完全反映现实情况。互联网是一个无限多样化的领域，总的来说，我们可能已经忘记了访问网站的个人使用的各种设备、互联网速度、屏幕尺寸、浏览器和浏览器版本——所有这些都会影响页面性能和用户交互。

Sentry 等应用程序性能监控工具从通过设备访问您网站的真实用户那里收集的大量现场数据，与在受控情况下使用高性能开发机器从单个样本获得的实验室数据相比，将对您网站的性能提供更精确的评估。Philip Walton 在 2021 年发布的 HTTP Archive 数据显示，“在 Lighthouse 上获得 100 分的所有页面中，近一半未达到推荐的核心 Web 生命力阈值。”

Web 性能超越了单一的核心 Web 重要指标或 Lighthouse 性能评级。我们的讨论超越了我们正在处理的基本数据类型。

Web 性能不仅仅包含统计数据

速度 网页性能讨论中，网页加载速度是主要关注点。虽然这是一个重要的考虑因素，但我们必须承认，速度在很大程度上受到业务目标和销售目标的影响。Google 在 2018 年发布的一份报告指出，一旦页面加载时间超过三秒，跳出率上升的可能性就会增加 32%，而加载时间超过十秒，跳出率就会飙升至 123%。因此，有必要加快页面加载速度，以提高销售转化率。降低跳出率的核心目的是加快页面加载速度。 加载中.

但“加载速度更快”究竟意味着什么？有一个阈值，超过这个阈值，我们就无法从物理上加快网页的加载速度。人类——以及连接他们的服务器——分散在全球各地，而当代互联网基础设施在任何给定时间只能传输有限量的数据。

问题的关键在于，页面加载并不是某个时刻发生的。在一篇题为“速度是什么？”的文章中，Google 阐明了页面加载事件是：

没有任何单一指标可以完全概括这一体验。加载过程中的许多情况都会影响用户是否认为加载过程“快速”，如果只关注其中一种情况，您可能会忽略剩余时间范围内发生的负面情况。

这里的关键术语是 经验. 真正的网络性能超越 指标 和 速度，更加注重 我们如何看待 页面加载和页面可操作性。这毫不费力地将我们引向了关于 Google Lighthouse 如何计算性能评级的讨论。（它与速度的关系显然比人们想象的要少。）

Google Lighthouse 性能得分是如何确定的？

Google Lighthouse 性能得分的计算涉及核心 Web 重要指标（例如首次内容绘制 (FCP)、最大内容绘制 (LCP)、累积布局偏移 (CLS)）和其他与速度相关的指标（例如速度指数 (SI) 和总阻塞时间 (TBT)）的加权合并，这些指标 在整个页面加载时间线上都很明显.

以下是这些指标在总体得分中的权重明细：

每个指标的权重分配可以让我们了解 Google 如何优先考虑有助于提供卓越用户体验的各种元素：

1. 网页应及时响应用户输入

主要加权指标是 总阻塞时间 (TBT)，用于检查 首次内容绘制 (FCP) 识别主线程可能长时间阻塞的情况，从而阻碍对用户命令的快速响应。只要主线程上发生 JavaScript 任务超过 50 毫秒，主线程就被视为“阻塞”。减少 TBT 可确保网站对有形的用户操作（例如键盘输入、鼠标点击等）做出响应。

2. 网页应显示相关内容，且不出现意外的视觉波动

随后权重较大的 Lighthouse 指标包括 最大的内容涂料 (LCP) 和 累积布局偏移 (CLS)。LCP 表示加载过程中页面主要内容已经完成的阶段 想必 已加载，因此 有价值的.

在假定主要内容加载完成后，保持视觉一致性对于确保无缝用户参与和防止意外视觉中断至关重要。不受突然的视觉运动 (CLS) 的影响。理想的 LCP 测量是任何低于 2.5 秒的持续时间（这比我们预期的要长得多，考虑到我们不断努力优化我们的网站以 尽快).

3. 加载网页内容

这 首次内容绘制 (FCP) 指标表示页面加载过程中用户能够辨别屏幕上内容的初始时刻，而 速度指数 (SI) 衡量在加载过程中内容的视觉呈现速度，直到页面达到“完成”状态。

您的页面评估基于使用 HTTP Archive 中的性能统计数据对实际网站的速度测量。值得称赞的 FCP 指标低于 1.8 秒，值得称赞的 SI 指标低于 3.4 秒。这些基准比人们在考虑速度时可能预期的要高。

优先考虑可用性而非速度

Google Lighthouse 的性能评估无疑更注重可用性，而非速度。您的 SI 和 FCP 可能表现出超快的速度，但如果您的 LCP 出现渲染延迟，由于复杂的图像或外部内容导致视觉偏移而导致 CLS，那么您的整体性能评估将比您的页面在显示 FCP 时略有滞后但避免导致任何 CLS 的情况更差。本质上，如果 JavaScript 通过阻塞主线程超过 50 毫秒来阻碍页面的响应能力，则性能评估将受到比页面略微延迟显示 FCP 时更不利的影响。

为了更好地理解每个指标的权重如何影响最终的性能评估，您可以尝试使用 Lighthouse 评分计算器上的滑动控件。下面是一个简单的表格，说明了偏重单个指标权重对总体性能评估的影响，证明了页面可用性和响应性比速度更重要。

Google Lighthouse 整体性能得分的计算方法是将每个原始指标值转换为 0 到 100 之间的分数，该分数基于其在 Lighthouse 得分分布中的位置，该分数源自 HTTP Archive 中真实网站性能数据的性能指标。从这些数学密集型数据中可以得出两个重要结论：

1. 您的 Lighthouse 性能得分是根据真实的网站性能数据来制定的，而不是孤立的。
2. 鉴于评分采用对数正态分布，各个指标值与总分之间的相关性是非线性的，这表明虽然可以显著提高表现不佳的分数，但提高已经很高的分数变得更具挑战性。

进一步了解如何确定指标分数，并在 developer.chrome.com 上以对数正态分布曲线的图形表示形式展示。

有可能超越Google灯塔吗？

我欣赏 Google 在讨论 Web 性能时强调可用性而非速度。它鼓励开发人员优先考虑创造真正的体验，而不是追求任意指标。尽管如此，我还是想，在今天的 2024 年时代，欺骗 Google Lighthouse 是否可行，让其将设计糟糕且无用的页面视为优秀。

我穿上实验服，戴上科学眼镜，开始调查。所有测试均按以下方式进行：

• 使用 Chromium Lighthouse 插件，
• 在使用 Arc 浏览器的隐身窗口中，
• 选择“导航”和“移动”配置（除非另有说明），
• 由我本人在实验室环境下进行（即没有真实世界的数据）。

尽管我的实验受控环境与本文开头的建议相矛盾，但事实证明，这项实验是一项有趣的尝试。我希望您能够了解到，Lighthouse 评分只是错综复杂的 Web 性能难题中的一个元素（尽管是次要元素）。此外，由于缺乏真实世界的数据，这些发现的相关性可能会受到质疑。

操纵 FCP 和 LCP 分数的策略

TL;DR：加载时展示最少的 LCP 合格内容，以提高 FCP 和 LCP 分数，直到完成 Lighthouse 评估。

FCP 表示页面加载过程的初始阶段，用户可以感知屏幕上的任何内容，而 LCP 表示加载时间轴中主要页面内容（例如，最大的文本或图像元素）可能已加载的时间点。快速的 LCP 有助于增强用户对页面质量的信心 好处“可能”和“有益”是这里要牢记的关键词。

识别 LCP 元素

Lighthouse 为 LCP 考虑的网页元素类别包括：

• <img> 标签
• <image> 标签内的 <svg> 标签
• 标签
• 通过以下方式加载背景图像的元素 url() 函数（不包括 CSS 渐变）
• 包含文本节点或内联级文本元素的块级元素

接下来的要素是 省略 由于认为它们缺乏有用的内容，因此不予考虑 LCP：

• 透明度为零的元素（用户不可见），
• 遮挡整个视口的元素（可能是背景元素），以及
• 占位符图像或具有边际熵的低信息内容图像（例如纯色图像）。

然而，在这种情况下，判断图像或文本元素是否有益是非常主观的，通常超出了机器算法能够可靠判断的范围。例如，我构建的一个页面仅包含 <h1> 标签，10 秒后，JavaScript 会将更多描述性内容插入 DOM，然后隐藏 <h1> 标签。

根据实验，Lighthouse 将标题标签视为最大的内容绘制 (LCP) 组件。到达此阶段时，页面的加载时间线已结束，但主要内容尚未完全加载。尽管如此，Lighthouse 仍假设内容在 10 秒窗口内加载完毕的可能性很高。令人惊讶的是，即使将标题替换为句号等简单标点符号，Lighthouse 仍会给出满分 100 分，这更不值一提。

此次试验表明，通过客户端 JavaScript 加载页面内容时，最好不要显示框架加载器屏幕。这是因为显示这样的屏幕需要在页面上加载其他元素。通过认识到此过程需要一些时间，并将网络请求从主线程转移到 Web Worker 以避免影响总阻塞时间，我们可以使用包含最小可行 LCP 组件的通用“启动画面”来获得更好的首次内容绘制 (FCP) 评分。这种方法让 Lighthouse 觉得页面比实际更方便用户使用。

所需的只是包含一个代表 FCP 的合法 LCP 组件。虽然我不建议在 2024 年通过客户端 JavaScript 加载主页内容（最好从内容交付网络提供静态 HTML 或在服务器上构建尽可能多的内容），但无论 Lighthouse 性能得分如何，也不建议使用这种“黑客”来获得积极的用户体验。此外，这种方法可能对搜索引擎索引没有好处，因为当主要内容不在 DOM 中时，搜索机器人无法找到它。

我进行了类似的试验，将各种随机图像伪装成 LCP，以进一步降低页面的实用性。然而，由于使用了较小的文件大小（通过第三方图像 API 进一步缩小并转换为“下一代”图像格式以提高页面加载速度），Lighthouse 将这些图像视为“占位符图像”或“熵值较低”的图像。因此，这些图像不会被识别为 LCP 组件，这是一个理想的结果，使 LCP 更不容易受到操纵。

使用 Chromium DevTools 在隐身模式下查看演示页面，亲眼见证结果。

然而，这种策略在许多其他情况下可能不那么有效。例如，Discord 在浏览器中对其应用程序进行硬刷新时采用了“启动画面”方法，导致性能得分令人失望，仅为 29 分。

与我的 DOM 注入演示相反，LCP 组件被识别为隐藏在启动画面后面的某些内容，而不是启动画面本身内的元素，这可能是由于我测试的聚焦文本通道中存在一个或多个大图像。可以说，Lighthouse 分数对于仅在身份验证后才可访问的应用程序意义不大，因为它们不需要被搜索引擎编入索引。

在应用程序提供用户生成内容的许多其他情况下，完全控制 LCP 组件可能具有挑战性，尤其是对于图像而言。

例如，如果您确实可以控制网页上所有图片的大小，则可以利用有趣的黑客或“优化”（带引号）来操纵系统。RentPath 在 2021 年展示了这一点，开发人员通过放大网页上的图片缩略图，将 Lighthouse 性能得分提高了 17 分。他们设法影响 Lighthouse 将 LCP 组件视为较大的缩略图之一，而不是页面上的 Google 地图图块，后者通过 JavaScript 加载的时间明显更长。

关键点在于，如果您留意 LCP 元素并对其进行控制，无论是通过类似 RentPath 的黑客技术还是您自己设计的黑客技术，还是通过真正的增强，都可以获得更高的 Lighthouse 性能分数。虽然我在本文中将启动画面方法描述为黑客技术，但这并不意味着这种体验无法提供有意义且令人愉快的用户体验。性能和用户体验都围绕着理解加载过程和意图。

操纵 CLS 分数的策略

快速摘要：在假设有足够的数据的情况下，推迟加载导致布局偏移的内容，直到 Lighthouse 测试可能完成。使用变换的 CSS 动画通常不会引起 CLS，除非与向 DOM 添加新元素相结合。

CLS 采用十进制来衡量，低于 0.1 的分数被视为良好，高于 0.25 的分数被视为较差。Lighthouse 根据用户会话期间发生的最显著的一系列意外布局偏移来计算 CLS，其中考虑了视口大小和两个渲染帧之间不稳定元素的移动。虽然个别布局偏移实例可能无关紧要，但一系列接连发生的偏移将对您的分数产生不利影响。

如果您知道您的页面在加载时会触发令人讨厌的布局偏移，则可以将它们推迟到页面加载完成后，从而欺骗 Lighthouse 假设没有 CLS 问题。在一个个人示例中，演示页面返回的 CLS 分数为 0.143，即使新添加的文本元素通过 JavaScript 迅速导致原始内容向上移动。通过使用 设置超时（） 功能，Lighthouse 无法检测到 CLS 的发生。

另一个演示页面虽然可能不如前一个页面实用且用户友好度较低，但仍然获得了 100 分的完美性能分数，因为附加元素是任意出现的，无需任何用户交互。

虽然在页面加载测试中推迟布局转换是可行的，但这种解决方法对于现场数据或长期用户体验并不有效，而这些是前面讨论过的更关键的因素。在对具有延迟布局转换的页面使用 Lighthouse 进行“时间跨度”测试时，它准确地报告了不令人满意的 CLS 分数，约为 0.186。

如果您有意创建类似于演示的混乱用户体验，您可以利用 CSS 动画和转换策略性地将内容带入页面视图。在 Google 的 CLS 指南中，它提到“内容从一个位置平滑过渡到另一个位置可以增强用户的理解力并引导他们完成状态变化”，再次强调了情境用户体验的重要性。

在下一个演示页面中，我利用 CSS 转换 规模（） 将文本元素动画化 0 到 1 并将它们重新定位在页面上。这些转换不会触发 CLS，因为当文档准备就绪时，文本节点已经存在于 DOM 中。我在实验过程中注意到，如果在页面加载后使用 JavaScript 将文本元素动态插入 DOM，然后进行动画处理，Lighthouse 将检测到 CLS 并进行相应的评估。

您无法操纵速度指数得分

速度指数分数是根据页面呈现时的视觉进度计算得出的。页面加载序列中内容加载得越快，结果就越有利。

可以尝试采用某些策略来欺骗速度指数，使其感知到较慢的加载顺序。相反，没有可行的方法可以人为地加快内容的加载速度。提高速度指数分数的唯一方法是优化网页以尽可能快地加载尽可能多的内容。虽然这种方法在当前的网络环境中可能并不完全实用（主要是因为它会危及设计师的角色），但您可以完全致力于通过以下方式降低速度指数：

• 直接从 CDN 提供静态 HTML 网页，
• 省略页面中的图像，
• 减少或删除 CSS，以及
• 停止加载 JavaScript 或任何外部依赖项。

你也无法真正操纵 TBT 分数

TBT 衡量 FCP 之后主线程被 JavaScript 活动阻塞以致于无法响应用户交互的总时长。理想的 TBT 分数应低于 200 毫秒。

大量使用 JavaScript 的 Web 应用程序（如单页应用程序）在页面加载期间在客户端执行复杂的状态计算和 DOM 调整（而不是在传输渲染的 HTML 之前在服务器上执行），往往会获得较差的 TBT 分数。在这种情况下，可以通过将所有 JavaScript 推迟到 Lighthouse 评估结束后来改变其 TBT 分数。尽管如此，仍需要提供占位符内容或加载屏幕以满足 FCP 和 LCP 要求并通知用户即将进行的活动。此外，还需要努力在使用的前端框架中导航。（避免加载最终在页面加载序列中某个不确定时刻加载不同 React 应用程序的占位符页面！）

有趣的是，尽管高级 JavaScript 功能在客户端活动中仍然很普遍，但当前 Web 环境中的创新正在促进集体努力，以减轻 TBT 分数低于标准的现象。许多前端框架与当代托管服务相结合，具有无需任何客户端 JavaScript 即可按需呈现页面和执行复杂逻辑的能力。虽然从客户端消除 JavaScript 并不是目标，但存在无数种减少其部署的可能性，从而降低页面加载期间主线程上计算任务过多的风险。

总结：Lighthouse 仍然只是一个大概的指南

Google Lighthouse 无法精确指出特定网站的所有缺陷。尽管 Lighthouse 的性能指标优先考虑页面可用性（即对用户操作的响应能力），但它无法全面识别 2024 年的所有可用性或可访问性问题。

2019 年，Manuel Matuzović 做了一个实验，故意制作了一个设计糟糕的网页，而 Lighthouse 却给了它正面的评价。我推测 Lighthouse 的表现会在五年后有所改善；然而事实并非如此。

在这个最终的演示页面中，CSS 和 JavaScript 使输入事件失效，导致页面对用户操作无响应。五秒钟后，JavaScript 会改变行为，允许与按钮交互。令人惊讶的是，该页面在性能和可访问性方面都保持了满分。

仅仅依靠 Lighthouse 来替代可用性评估和逻辑推理是不可取的。

其他奇思妙想

在生活的各个方面，都存在着一种操纵系统的策略。下面介绍一些行之有效且有保证的策略，可以人为地提高您的 Lighthouse 性能得分，超越所有其他策略：

• 专门针对高速和顶级硬件进行 Lighthouse 评估。
• 确保您的互联网连接处于最佳状态；如果需要，请重新定位。
• 仅利用实验室数据，不结合使用上述高速硬件和出色的互联网连接收集的实际使用数据。
• 利用本文详述的所有巧妙的技巧在不同的实验室条件下重复评估，直到获得预期的结果，从而给您的熟人、同事和互联网陌生人留下深刻印象。

重要的: 要深入了解 Web 性能并提升网站优化技能，请考虑采用 Sentry 等应用程序监控工具。将 Lighthouse 视为初步指标，将 Sentry 视为最终的生产数据捕获、高效、Web 生命体征监测工具。

总而言之，这里是用于教育目的的完整演示网站的链接。