Web Performance

如何阅读 Lighthouse 报告而不慌张

一份实用指南：理解性能审计中真正重要的内容，以及哪些可以安全忽略

The Wux Webtools Team The Wux Webtools Team 7 分钟阅读 人工智能辅助，人工审核
Stylized lighthouse beam illuminating a clear path through fog, representing clarity in performance diagnostics
目录
  1. 第一条规则：分数不等于你的网站
  2. 先看什么：Core Web Vitals
  3. 机会 vs. 诊断：理解区别
  4. 通常可以忽略的审计项
  5. 当一切都是红色时该怎么办
  6. 实验室数据 vs. 现场数据：现实校验
  7. 何时重新运行 Lighthouse
  8. 帮助你处理 Lighthouse 发现项的工具
  9. 要点总结
  10. FAQ
  11. Sources

第一条规则：分数不等于你的网站

第一次打开 Lighthouse 报告时，你会看到一整面数字、按颜色编码的方框，以及一些你从未听说过的警告。自然反应往往是恐慌。分数是红色的。有十七项审计未通过。网站肯定坏了？

很可能不是。Lighthouse 是诊断工具，不是成绩单。这个分数是在实验室条件下运行的合成基准测试——通常是在限速连接上，模拟一台 2017 年的中端手机。它告诉你网站在这个特定场景下的表现，而不是真实用户在实际环境中的体验。

这一点很重要，因为大多数团队会盯着分数，却忽略上下文。对于一个带有实时数据的复杂 Web 应用来说，65 分可能完全可以接受。即使拿到 95 分，如果优化方向不对，用户体验也可能很差。分数是调查的起点，而不是成功指标。

先看什么：Core Web Vitals

先跳过整体性能分数。向下滚动到 Metrics 部分，查看三个数字：Largest Contentful Paint (LCP)、Cumulative Layout Shift (CLS) 和 Interaction to Next Paint (INP)。这些就是 Core Web Vitals，也是 Google 用作排名信号的唯一性能指标。

  • LCP 衡量最大可见元素渲染出来需要多长时间。目标：低于 2.5 秒。如果超过 4 秒，用户等待看到有意义内容的时间就太长了。
  • CLS 衡量视觉稳定性——页面加载时跳动的程度。目标：低于 0.1。如果超过 0.25，用户可能会因为按钮移动而误点错误内容。
  • INP 衡量响应性——页面对点击、轻触和按键的反应速度。目标：低于 200ms。如果超过 500ms，网站会显得迟钝。

这三个指标与真实用户的挫败感相关。在担心其他任何事情之前，先修复它们。

机会 vs. 诊断：理解区别

Lighthouse 将发现的问题分为两类：机会 和 诊断。机会会按预估节省时间排序。诊断则是额外上下文——有些可能是问题，也可能不是。

从机会开始。如果 Lighthouse 说“消除阻塞渲染的资源”可以节省 1.2 秒，那就是一个明确的收益。如果它说“减少未使用的 JavaScript”只能节省 0.1 秒，通常不值得为此重构。

诊断要更微妙一些。“避免 DOM 规模过大”听起来很糟，但如果你的 CLS 正常、INP 也很快，一个较大的 DOM 可能并没有伤害任何人。诊断是线索，不是命令。优先调查那些与你实际指标相吻合的问题。

通常可以忽略的审计项

有些 Lighthouse 警告是历史遗留或过于激进的。以下几项最容易造成不必要的恐慌：

  • “未使用 passive 监听器来改善滚动性能” —— 这是一个很少能带来明显改善的微优化。除非你有滚动卡顿的证据，否则可以跳过。
  • “图片元素没有显式 width 和 height” —— 这会影响 CLS，但前提是图片确实导致了布局偏移。如果你的 CLS 已经很好，就不要为了通过审计而重构。
  • “使用新一代格式提供图片” —— 是的，WebP 和 AVIF 更小。但如果你的图片已经优化过，而且 LCP 很快，这只是锦上添花，不是危机。
  • “避免巨大的网络负载” —— Lighthouse 会标记任何超过 1.6 MB 的页面。但一个加载很快的 2 MB 页面，比一个阻塞渲染的 500 KB 页面更好。关注字节是如何交付的，而不只是总量。

当一切都是红色时该怎么办

如果你的 Lighthouse 分数低于 50，并且大多数审计项都失败了，你很可能遇到了以下三个根因之一：

  1. 未优化的字体。 Web 字体仍然是大多数网站上最容易获得的性能收益。检查你是否加载了六种字重却只用了两种，或者是否在发送 WOFF 文件而不是 WOFF2。
  2. 阻塞渲染的 CSS 和 JavaScript。 如果你的 First Contentful Paint (FCP) 超过 3 秒，说明有东西阻止了浏览器绘制。检查 <head> 中的大型 CSS 文件或同步脚本。
  3. 过大的图片。 如果你的 LCP 元素是一张图片，而且它有 4 MB，那就是问题所在。压缩它，对首屏以下图片使用懒加载，并使用响应式图片语法。

修复其中一个问题，然后重新运行 Lighthouse。你通常会看到 20–30 分的提升。然后再处理下一个。

实验室数据 vs. 现场数据：现实校验

Lighthouse 在实验室中运行。它会模拟慢连接和慢设备，但无法模拟真实用户行为——人们如何滚动、点击什么、是否处在不稳定的 Wi-Fi 环境中。

要进行现实校验，请将 Lighthouse 结果与来自 Chrome User Experience Report (CrUX) 的现场数据进行比较。CrUX 展示过去 28 天中真实 Chrome 用户对你网站的体验。如果 Lighthouse 说你的 LCP 是 4 秒，但 CrUX 显示是 2 秒，请相信 CrUX。如果两者都很糟，那你确实有一个真实问题。

你可以在 PageSpeed Insights（Lighthouse 的网页版）中找到 CrUX 数据，也可以在 Google Search Console 的“Core Web Vitals”下查看。如果两者不一致，就调查原因。也许你的真实用户使用的是更快的网络。也许 Lighthouse 正在测试一个未优化的开发构建。

何时重新运行 Lighthouse

Lighthouse 存在噪声。连续运行三次，你会得到三个不同的分数，即使是在同一个页面上也是如此。这是因为性能本身是可变的——后台进程、网络抖动和浏览器启发式策略都会影响结果。

要获得稳定的基线，请在禁用所有扩展的无痕模式下运行 Lighthouse，或者使用带有 --preset=desktop 标志的 CLI 来获得更一致的结果。运行三次并取平均分。如果你看到大幅波动（超过 10 分），说明还有其他问题——可能是服务器很慢，或者页面每次加载的资源不同。

每次进行重大更改后都重新运行 Lighthouse。部署了新的字体策略？检查 LCP。对图片使用懒加载？检查 CLS。添加了第三方脚本？检查 INP。性能不是一次性修复；它是一项需要持续守护的预算。

帮助你处理 Lighthouse 发现项的工具

Lighthouse 会告诉你什么慢。它并不总是告诉你如何修复。为此，你需要额外的工具：

  • WebPageTest 提供页面加载过程的胶片视图，逐帧展示。它对诊断 LCP 和 CLS 问题非常关键。
  • Chrome DevTools Performance panel 会精确显示哪些 JavaScript 正在阻塞主线程。用它来定位糟糕 INP 分数的来源。
  • 图片压缩工具 让你可以直接在浏览器中优化图片，这比上传到第三方服务更快，也更私密。客户端图片处理对隐私更有利，因为你的图片从不会离开你的机器。

Lighthouse 是起点。这些工具帮助你完成后续工作。

要点总结

  • 你的 Lighthouse 分数是实验室基准，不是对真实用户体验的衡量。恐慌之前，先把它与 CrUX 的现场数据对比。
  • 首先关注 Core Web Vitals（LCP、CLS、INP）。这些指标与用户挫败感和 SEO 影响相关。
  • 按预估节省时间优先处理机会项。忽略那些与你实际性能问题不一致的诊断项。
  • 有些审计项——例如 passive 监听器或新一代图片格式——是微优化。先修复大的问题。
  • 运行 Lighthouse 三次并取平均结果。性能是可变的，单次运行可能具有误导性。

FAQ

Q: 为什么我每次运行 Lighthouse，分数都会变化？
A: Lighthouse 在可变条件下测量性能——网络速度、CPU 负载和浏览器启发式策略都会影响结果。请在无痕模式下运行三次，并取平均分，以获得更稳定的基线。

Q: 我应该先优化移动端还是桌面端？
A: 移动端。Lighthouse 默认使用移动端模拟，因为大多数 Web 流量来自移动设备，而移动设备更慢。如果你的移动端分数很好，桌面端分数通常也会不错。

Q: 我的 Lighthouse 分数是 95，但网站仍然感觉很慢。问题在哪里？
A: Lighthouse 衡量的是页面加载，而不是加载后的交互性。检查你的 INP 分数，并使用 Chrome DevTools Performance panel 分析用户点击或滚动时发生了什么。你可能有一个 Lighthouse 没有捕捉到的 JavaScript 问题。

Q: 我需要拿到完美的 100 分吗？
A: 不需要。90+ 的分数已经非常优秀。追求 100 往往意味着优化那些对用户并不重要的东西。专注于真实指标——LCP、CLS、INP——并忽略分数。

Q: 如果我使用了很多第三方脚本，还能信任 Lighthouse 吗？
A: Lighthouse 会将第三方脚本标记为问题，但它并不总能区分哪些是必要的、哪些是不必要的。使用“避免巨大的网络负载”和“减少 JavaScript 执行时间”审计来识别最严重的违规项，然后再决定是否值得保留。

Sources

Flowchart for reading a Lighthouse report: ignore score first, check LCP CLS INP, review Opportunities by time savings, then use Diagnostics as context
InfographicHow to triage a Lighthouse report — A simple order of operations turns a scary report into a short prioritized checklist
Two-column comparison of Lighthouse items to prioritize versus warnings that can often wait, with examples and numeric thresholds
InfographicLighthouse signals: fix now vs usually ignore — Not every red warning deserves engineering time
Side-by-side diagram comparing Lighthouse lab data and CrUX field data, including 28-day real-user window and example LCP mismatch
InfographicLab data vs field data at a glance — Use lab data to diagnose and field data to confirm what users really feel

常见问题

为什么我每次运行 Lighthouse，分数都会变化？
Lighthouse 在可变条件下测量性能——网络速度、CPU 负载和浏览器启发式策略都会影响结果。请在无痕模式下运行三次，并取平均分，以获得更稳定的基线。
我应该先优化移动端还是桌面端？
移动端。Lighthouse 默认使用移动端模拟，因为大多数 Web 流量来自移动设备，而移动设备更慢。如果你的移动端分数很好，桌面端分数通常也会不错。
我的 Lighthouse 分数是 95，但网站仍然感觉很慢。问题在哪里？
Lighthouse 衡量的是页面加载，而不是加载后的交互性。检查你的 INP 分数，并使用 Chrome DevTools Performance panel 分析用户点击或滚动时发生了什么。你可能有一个 Lighthouse 没有捕捉到的 JavaScript 问题。
我需要拿到完美的 100 分吗？
不需要。90+ 的分数已经非常优秀。追求 100 往往意味着优化那些对用户并不重要的东西。专注于真实指标——LCP、CLS、INP——并忽略分数。
如果我使用了很多第三方脚本，还能信任 Lighthouse 吗？
Lighthouse 会将第三方脚本标记为问题，但它并不总能区分哪些是必要的、哪些是不必要的。使用“避免巨大的网络负载”和“减少 JavaScript 执行时间”审计来识别最严重的违规项，然后再决定是否值得保留。

来源与进一步阅读

  1. Lighthouse performance scoring — Google Developers
  2. Core Web Vitals — web.dev
  3. Chrome User Experience Report — Google Developers
  4. WebPageTest Documentation — WebPageTest.org
#lighthouse #core-web-vitals #beginners #performance #web-performance
关于作者
The Wux Webtools Team

最后更新:

继续阅读