Chrome Lighthouse 详解

一、Lighthouse 是什么

Lighthouse 是 Google 开源的自动化网页质量审计工具，它会打开一个网页、执行一系列审计检查，最终产出一份带评分和优化建议的报告。

用途：衡量网页在「性能、无障碍、最佳实践、SEO」等方面的表现，帮助你定位问题并改进。
运行方式 ：可以针对任何网页运行，包括需要登录（身份验证）的网页。
本质：一个开源项目 + 一个 Node.js 模块，底层由 Chrome DevTools Protocol 驱动，在无头 Chrome 中模拟真实加载过程采集数据。
适用人群：前端工程师、性能优化工程师、SEO 运营、测试/QA、想提升网站质量和用户体验的任何开发者。

一句话：Lighthouse 相当于给网页做一次「全面体检」，最后打分数、给病历、开药方。

二、四种常用运行方式

方式	适用场景	说明
Chrome DevTools 面板	本地开发、快速查看	DevTools → Lighthouse 标签 → 选择类别 → Analyze，一次点击出报告，支持「生成报告(JSON)」导出
命令行 CLI（lighthouse-cli）	脚本化、CI、批量	`npx lighthouse <URL>`，可输出 HTML / JSON 报告，可配设备、节流、类别
Node 模块	深度集成、自研工具	`const {lighthouse} = require('lighthouse')`，程序化控制采集与结果解析
PageSpeed Insights（线上）	无需本地环境、测线上环境	输入网址即测，同时给出「实验室」与「现场（CrUX 字段数据）」两种数据
Chrome 扩展	离线一键测	Lighthouse 官方扩展，直接在浏览器里点图标运行

提示：DevTools 里测试的是本地模拟环境 ，PageSpeed Insights 测的是真实线上 URL，两者结果可能不同。

三、审计类别（Categories）

Lighthouse 按多个类别分别打分（0--100），每个类别由若干条「审核项（audits）」构成。

类别	作用	主要关注点
性能 Performance	衡量加载速度与体验	FCP / LCP / TBT / CLS / SI 等核心指标
无障碍 Accessibility	是否所有用户（含残障人士）都能访问	语义化标签、ARIA、对比度、可键盘操作
最佳实践 Best Practices	代码健康度与安全	HTTPS、控制台报错、浏览器兼容、安全隐患
SEO	是否利于搜索引擎收录与排名	可索引性、meta 描述、链接可抓取性、robots
Agentic Browsing（v13 新增）	网页能否被 AI 代理高效理解和操作	可访问性树完整性、CLS 稳定性、`llms.txt` 存在性

类别演进说明：

早期版本曾有独立的 PWA（渐进式 Web 应用） 类别，自 Lighthouse v12（2024） 起，PWA 相关审核从默认类别中移除，DevTools 默认不再单列 PWA 评分。
Agentic Browsing 是 2026 年新增的类别，聚焦「机器/AI 代理能否顺畅浏览你的网页」，核心检查包括：
1. 面向代理的无障碍（agent-centric accessibility）：可访问性树中最影响机器交互的部分，如命名、标签、树完整性与可见性；
2. 稳定性与可发现性 ：测量 CLS，并检查是否存在 llms.txt 文件。

四、性能评分权重（Performance Score）

性能得分 = 各指标得分的加权平均。注意：只有「指标（Metrics）」直接影响性能总分，「优化建议（Opportunities）」和「诊断（Diagnostics）」不直接加权，但它们改善后会间接提升指标值。

当前权重（Lighthouse 10 至今）

指标	权重
Total Blocking Time（TBT，总阻塞时间）	30%
Largest Contentful Paint（LCP）	25%
Cumulative Layout Shift（CLS）	25%
First Contentful Paint（FCP）	10%
Speed Index（SI，速度指数）	10%

指标得分如何得出

每个原始指标值（大多以毫秒计）会根据它在真实网站性能分布中的位置，映射为 0--100 的指标得分。
评分曲线基于 HTTPArchive 真实网站数据拟合的对数正态分布：
- 第 25 百分位 → 50 分（中位数控制点）
- 第 8 百分位 → 90 分（良好/绿色控制点）
- 得分约 0.96 附近是「边际效益递减点」，分数越高，每提升 1 分需要的改进越多（从 99→100 的难度 ≈ 90→94）。
移动端与桌面端使用各自的评分曲线（Lighthouse v6 修复了此前桌面端分数虚高的问题）。

分数颜色区间

区间	颜色	含义
0 -- 49	🔴 红色	较差
50 -- 89	🟠 橙色	需要改进
90 -- 100	🟢 绿色	良好

建议目标 90+。满分 100 极难也不现实，性价比不高。

五、六大核心指标详解

下面逐个拆解指标：定义、判定阈值、如何优化。

1. FCP（First Contentful Paint，首次内容绘制）

定义：从发起加载到页面首次渲染出任何内容（文本、图片、canvas 等）的时间。
阈值：良好 ≤ 1.8s ｜较差 > 3.0s
优化方向 ：减少首屏阻塞资源（render-blocking 的 CSS/JS）、内联关键 CSS、精简首屏 HTML、消除重定向。

2. SI（Speed Index，速度指数）

定义：页面内容可视化完成的快慢，通过首屏加载过程中页面可视完成的进度衡量，值越低越好。
阈值：良好 ≤ 3.4s ｜较差 > 5.8s
优化方向：缩短首屏渲染完成时间，避免内容迟迟不出现（占位、骨架屏、渐进式渲染）。

3. LCP（Largest Contentful Paint，最大内容绘制）

定义：加载过程中最大可见元素（图片、大文本块、视频封面等）渲染完成的时间。反映「主要内容何时可用」。
阈值：良好 ≤ 2.5s ｜较差 > 4.0s
优化方向 ：优化最大元素（通常是首屏大图/大标题）、图片懒加载之外的预加载、priority 提示、CDN、压缩、避免阻塞。

4. TBT（Total Blocking Time，总阻塞时间）

定义：FCP 之后，主线程被长任务阻塞、无法响应输入的时间总和（所有 >50ms 长任务超出 50ms 部分之和）。衡量「交互响应延迟」。
阈值：良好 ≤ 200ms ｜较差 > 600ms
优化方向：拆分/延迟 JavaScript、减少第三方脚本、代码分割、优化主线程工作。

5. CLS（Cumulative Layout Shift，累积布局偏移）

定义：页面加载期间视觉元素意外移动的总量，衡量视觉稳定性。
阈值：良好 ≤ 0.10 ｜较差 > 0.25
优化方向 ：为图片/视频/广告预留尺寸空间、避免在已有内容上方插入内容、使用 aspect-ratio、避免影响布局的动画。

6. TTI（Time to Interactive，可交互时间）

定义：页面从加载到可稳定响应输入的时间（FCP 之后，主线程空闲且事件监听器就绪）。
阈值：良好 ≤ 3.8s ｜较差 > 7.3s
说明：Lighthouse 8 之前参与总评分，当前版本不再计入总分，但仍会报告该值供参考。

Core Web Vitals（核心 Web 指标）

Google 对「用户体验最重要」的三个指标有官方定义，也是 SEO 排名信号：

指标	衡量	良好阈值
LCP	加载性能	≤ 2.5s
INP（Interaction to Next Paint）	交互响应	≤ 200ms
CLS	视觉稳定性	≤ 0.1

注意：2024 年起 INP（Interaction to Next Paint，与下一次绘制之间的交互延迟）取代了 FID ，成为衡量交互响应的核心指标。Lighthouse 实验室中通过 TBT 近似反映交互性能，而 INP 主要通过现场字段数据（CrUX） 获取。

六、如何看懂报告

一份 Lighthouse 报告通常包含以下区域：

总体评分区：各类别圆形/条形分数，配颜色。
指标区（Metrics）：六大实验室指标的实测值，标注好坏颜色。
优化机会（Opportunities）：最有性价比的优化项，按「预计可节省的时间」排序。
诊断（Diagnostics）：更多潜在问题的说明与文档链接。
已通过的审核（Passed audits）：通过项列表。
运行信息（Runtime settings / environment）：设备类型（移动/桌面）、网络节流、UA、所用的 Lighthouse 版本等。

每条审核项都链接到官方文档，说明「为什么重要」和「怎么修」，可直接点进去逐条对照落地。

七、在 CI/CD 中集成（Lighthouse CI）

使用 lighthouse-ci 工具可在每次代码提交时自动跑性能预算，防止性能回归。
常用做法：设置性能预算（budgets），如「LCP < 2.5s」「总 JS 体积 < 300KB」，超标则 CI 失败。
支持与 GitHub Actions / 自建流水线 / Docker 集成，报告可存为 JSON 便于 diff 与归档。
基本思路：npx lhci autorun 采集 → 与预算比对 → 生成报告 → 决定是否通过。

八、常见性能优化清单（速查）

图片：WebP/AVIF 格式、压缩、loading="lazy" + aspect-ratio 防抖动、首屏大图 preload/fetchpriority。
CSS：内联关键 CSS、移除未使用 CSS、避免 render-blocking。
JavaScript：代码分割、按需加载、移除/延迟第三方脚本、长任务拆分。
网络：HTTP/2/3、CDN、缓存策略（强缓存/协商缓存）、Gzip/Brotli 压缩。
渲染：减少 DOM 规模、避免布局抖动、使用 content-visibility。
稳定性：为动态内容预留空间、控制 CLS。
无障碍：语义化标签、足够的颜色对比度、ARIA 角色、键盘可达性。
SEO ：唯一 title、meta description、可索引、有效 robots、llms.txt（针对 AI 代理）。

九、局限性 & 使用注意事项

实验室数据 ≠ 真实用户数据：Lighthouse 是在受控模拟环境下测的「实验室数据」；真实用户的「现场数据」由 Chrome UX Report（CrUX）提供，两者结合看更全面。
评分会波动：A/B 测试、广告变动、路由、设备差异、浏览器扩展、杀毒软件等都会影响结果，别只盯单次分数，应看多次结果的分布。
别盲目追 100 分：分数只是代理指标，优先优化真正影响用户感知的 LCP / INP / CLS。
移动/桌面分开看：两者评分曲线不同，测移动端更能代表多数用户（尤其国内移动流量占比高）。
版本差异：不同 Lighthouse 版本权重与审核项不同，跨版本比较总分需谨慎。

十、重要版本演进时间线

版本	年份	关键变化
v6	2020	桌面端独立评分曲线；CLS 加入评分
v8	2021	TTI 权重下调、TBT 权重上调
v10	2023	评分权重调整为 TBT 30% / LCP 25% / CLS 25%（沿用至今）
v12	2024	移除默认 PWA 类别；适配 INP 取代 FID
v13.4	2026-06	新增 Agentic Browsing 类别；随 Chrome 151 与 PageSpeed Insights 上线