8.3 Lighthouse评分实战

8.3 Lighthouse 评分实战

前两节的优化需要一个公开的裁判。本节把 Lighthouse 审计跑成工作流：怎么跑分才可信、报告怎么读、扣分项怎么映射到本教程的具体章节、修复后怎么验证。末尾给出一份"分数守护"的团队实践——性能是易失物，没有守护就随迭代流失。

跑一份可信的报告

Lighthouse 内置在 Chrome 开发者工具里，但随手一跑的分数并不可信。标准姿势：

环境要求（跑分前逐项确认）：
1. 无痕窗口：扩展程序会污染测量
2. 构建+preview 或部署到预发：不用 dev 服务器（dev 无优化）
3. 明确节流档位：移动端默认 Slow 4G + 4x CPU 减速——分数是"移动端弱网"口径
4. 跑三次取中位：单次波动可达十分
5. 测关键页而非只测首页：商品详情、列表页各有各的病
​

命令行版可进 CI（第 9 章会把它接进流水线）：

# 对预发地址跑移动端全项审计
npx lighthouse https://staging.example.com \
  --preset=desktop=false \
  --output=json --output-path=./lh-report.json \
  --chrome-flags="--headless"
​

报告怎么读

四大分类各有关键词：

• Performance：分数是 LCP/INP/CLS/FCP/TBT 的加权综合——看子指标比看总分有用，总分是果，子指标是因；
• Accessibility：对比度、标签缺失、图像无 alt——第 9 章 9.4 无障碍的主战场；
• Best Practices：控制台报错、过期 API、混合内容；
• SEO：标题描述缺失、robots 不可抓、链接不可点（8.2 的直接兑分区）。

诊断区块（Diagnostics）比分数更有价值：它列出"机会"（Opportunities，估计节省的毫秒数）与"诊断"（Diagnostics，问题清单），每条都能点开看受影响的资源。

图 8-3：扣分项到章节的归因地图

一次完整实战：把商品页从红区拉回绿区

背景：某商品详情页移动端 Performance 五十八分，LCP 四秒六，CLS 零点二四。按循环走：

第一轮，归因 LCP。报告诊断指出 LCP 元素是主视觉图，且该图被 lazy。落到 8.1 的例外规则——首屏主图改为 preload 加高优先级，补 width/height。复测：LCP 三秒八。诊断更新：剩余耗时在"渲染阻塞资源"——一个外链字体 CSS。

第二轮，治字体。外链字体换自托管（7.3 字体模块），字重四个砍两个，回退度量对齐。复测：LCP 三秒一，CLS 降到零点零六（字体移位消失立竿见影）。

第三轮，砍首屏 JS。体积分析（7.1 的 NITRO_ANALYZE）发现一个全量引入的图标库占四百多 KB。换按需引入，首屏分片从八百九十 KB 降到三百二十 KB。复测：TBT 从六百八十毫秒降到两百一十，INP 转绿，Performance 七十九分。

第四轮，收尾。剩余扣分是两张视口外图片与接口耗时——图片加懒加载（8.1），接口加 storage 缓存（6.2）。终测：Performance 九十一，三大指标全绿。

复盘这段过程：四轮动作没有一个是"新知识"，全是前章清单的执行——这正是 8-3 那张归因图的价值，把报告语言翻译成"翻哪章、做什么"。

分数守护：别让优化白做

性能是易失物：下个迭代加个组件、引个依赖，分数悄悄掉回去。守护三件套：

1. CI 阈值：流水线跑 Lighthouse，核心指标设预算线（如 LCP 预算两秒五），超标即红——第 9 章 CI 一节的实战项；
2. 报告入库：每次跑分的 JSON 存进仓库，性能讨论有据可查；
3. 真实用户监控：合成测量之外，接 RUM（第 9 章 9.2 监控话题）看真实用户的三指标分布——实验室分数好，真实网络差的情况只有 RUM 能暴露。

团队的分数文化

工具之外，分数管理最终是团队文化问题。三种常见的不良姿态值得警惕。

姿态一：分数 KPI 化。把"Performance 必须九十以上"写进考核，团队的反应不是优化而是取巧——砍掉有价值的功能组件换取分数、把重页面拆成无数空壳导航页。分数是健康度的代理指标，代理指标一旦成为目标就失真（这正是度量定律的经典案例）。正确的做法是把三大核心指标的 P75 真实数据（9.2 的 RUM）作为北极星，Lighthouse 分数只是发布前的快速体检。

姿态二：一次冲刺定终身。性能专项做完拿到九十分，半年后再测回到七十——每个迭代都在悄悄扣分，一个重依赖、三张未压缩的图、一处接口退化。分数守护必须是持续机制（CI 预算线加 RUM 监控），一次性的"性能月"无法对抗熵增。

姿态三：全站一把尺。用首页的分数代表全站。搜索页、详情页、结算页各有各的资产结构与瓶颈，各自的基线与预算应当分开设定。首页九十分、结算页不及格的站点，在流失率上照样付出代价——转化最关键的那一页恰恰最慢，是内容电商的经典悲剧。

健康的分数文化长这样：每个关键页面有独立基线与预算，发布流水线自动把关，RUM 曲线进周报，性能回退像构建失败一样自然地阻断发布。做到这一步，性能才从"个人英雄主义的优化"变成"团队的工程常态"。

常用审计命令速查

把本节用到的命令收进工具箱：

# 命令行跑单页审计（CI 集成的基础形态）
npx lighthouse https://example.com --output=json --output-path=report.json --chrome-flags="--headless"

# 只跑性能类目，输出 HTML 报告便于人工查看
npx lighthouse https://example.com --only-categories=performance --view

# 多页面批量审计（循环跑关键页清单）
for p in / /products /checkout; do
  npx lighthouse "https://example.com$p" --output=json --output-path="lh-$(echo $p | tr '/' '_').json" --chrome-flags="--headless"
done
​

批量跑出的 JSON 用脚本提取核心指标汇总成表（Foreach 读 audits 字段的 numericValue），贴进 PR 描述——评审者在合并前就能看到这次改动的性能影响，这是"分数守护"成本最低的落点。

⚠️ 常见坑：为凑分过度优化。图片压到失真、砍掉必要的动画反馈、把功能塞进懒加载让交互变慢——分数是用户体感的代理指标，不是目标本身。九十五分以上每提一分，常要拿体验细节去换，评估值不值。

💡 关键直觉：Lighthouse 报告是"体检单"而不是"成绩单"——子指标是病因，总分只是体温。会读病因的人改三行代码涨十分，只盯体温的人改三十行涨两分。

本节要点回顾

• 跑分五纪律：无痕、生产构建、明确节流、三次取中、覆盖关键页；
• 读报告看子指标：LCP/INP/CLS 是因，总分是果；诊断区块的"机会"按估计节省排序；
• 归因地图：每个扣分项都能映射到具体章节的具体动作，修复循环一次只动一件事；
• 实战四轮：preload 主图、自托管字体、按需图标、懒加载加缓存——九十一分由一串小修复堆出来；
• 守护三件套：CI 预算线、报告入库、RUM 真实监控，防性能随迭代流失。