10 分钟读透 Lighthouse 报告HTML 与 JSON 双格式速成指南【免费下载链接】lighthouseAutomated auditing, performance metrics, and best practices for the web.项目地址: https://gitcode.com/GitHub_Trending/lig/lighthouse跑完一次 Lighthouse 审计后大多数人卡在同一处一份几百 KB 的 JSON、一个可以随便点来点去的 HTML 页面指标几十个却不知道先翻哪一页、该把报告发给谁。这篇 Lighthouse 报告解读指南不讲格式规范只讲用法——30 秒定格式三步读完 HTML再带你看 JSON 里真正值得盯的字段。30 秒选型这份报告该用 HTML 还是 JSON先给结论省得你在--help里翻半天参数定义在 cli/cli-flags.jsHTML给人看的。丢给产品、丢给设计、贴进评审文档。优点是自带展开/折叠和颜色分区缺点是机器没法直接读。JSON给脚本看的。CI 取数、版本对比、批量巡检全靠它。人读着费劲但字段稳定。两个都要CLI 的--output本身接受数组一条命令可以同时产出多份这是最常见的姿势。一句话记忆报告要展示就用 HTML要计算就用 JSON。HTML 报告三步读法打开报告后别急着往下滚按固定顺序走总分顶部一排圆形仪表性能、可访问性、最佳实践、SEO 各占一格分数是各类别内审计项的加权平均。先找分最低的那格后面所有时间都花在上面。失败项切到弱项分类只看红色条目。每条展开后详情面板里带表格——哪张图、哪行 JS、哪个节点出的问题行/列和 DOM 节点都能对号入座。建议失败项下方会直接给出修复方向和预估收益比如能省多少毫秒。按收益排序干活别按字母序。JSON 报告字段地图与取数姿势LHRLighthouse 结果对象的字段结构在 proto/lighthouse-result.proto 里有完整定义日常真正用到的是这几个lighthouseVersion/fetchTime先核对版本和采集时间跨版本对比数据前先对齐这一项。categories每个类别的score是 0 到 1 的加权分auditRefs里的weight决定谁在拖累总分。audits按 id 取单项如audits[largest-contentful-paint]displayValue是报告里展示给人看的那个值details装明细。configSettings/environment节流方式、设备模拟、benchmarkIndex机器性能档位。两次结果对不上时先查这两处口径是否一致。timing整个审计耗时排查审计本身慢的问题用。取数交给jq两行搞定jq .categories.performance.score lighthouse-results.report.json jq [.audits | to_entries[] | select(.value.score ! null and .value.score 0.5)] | .[].value.id lighthouse-results.report.json一条命令出双份报告--output可重复传--output-path传同一个基名CLI 会自动补扩展名规则见 cli/ 下的实现lighthouse https://example.com \ --outputhtml --outputcsv \ --output-pathreports/my-run跑完得到reports/my-run.report.html和reports/my-run.report.jsonHTML 发给同事看结论JSON 留在仓库里进 CI。后续想只跑部分审计或类别再加--only-audits/--only-categories即可配置细节看 docs/configuration.md。把审计变成习惯清单很短照着做就行固定节奏上线前、大促前各跑一轮别想起来才跑。JSON 入库每次运行结果按日期落盘天然就是趋势数据源。设门槛CI 里用jq读categories.*.score低于阈值直接红掉流水线。留档分享评审会发 HTML归档和回溯用 JSON各司其职。【免费下载链接】lighthouseAutomated auditing, performance metrics, and best practices for the web.项目地址: https://gitcode.com/GitHub_Trending/lig/lighthouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考