Lighthouse 评分机制完全解读：Performance、Best Practices、SEO 与 Accessibility 得分究竟如何计算

Lighthouse 评分机制完全解读Performance、Best Practices、SEO 与 Accessibility 得分究竟如何计算【免费下载链接】lighthouseAutomated auditing, performance metrics, and best practices for the web.项目地址: https://gitcode.com/GitHub_Trending/lig/lighthouseLighthouse 会把每次审计结果汇总为 0~100 的整体得分但不同类别Category背后的计分规则截然不同有的类别等权相加有的类别是加权平均还有的类别依赖对数正态分布换算。本文以 docs/scoring.md 为主体结合仓库中 core/scoring.js、core/config/default-config.js 等源码完整拆解四类分数的计算原理、权重来源与实战提升方法帮助你真正读懂 LHRLighthouse Result中的每个数字而不是只盯着红黄绿三种颜色。一切得分的公共底座加权平均引擎无论哪个类别最终得分都由同一个引擎计算得出。Lighthouse 将“类别得分”定义为类别下所有审计得分的加权平均值实现在 core/scoring.js 的ReportScoring类中static arithmeticMean(items) { // Filter down to just the items with a weight as they have no effect on score items items.filter(item item.weight 0); // If there is 1 null score, return a null average if (items.some(item item.score null)) return null; const results items.reduce( (result, item) { const score item.score; const weight item.weight; return { weight: result.weight weight, sum: result.sum /** type {number} */ (score) * weight, }; }, {weight: 0, sum: 0} ); return clampTo2Decimals(results.sum / results.weight || 0); }这里有三个值得注意的细节空数组返回 0当类别下没有任何带权重的审计时arithmeticMean([])结果为 0任一审计得分为 null 时整体返回 null某个审计因运行出错error模式等原因没有得分会导致整个类别无分结果保留两位小数clampTo2Decimals通过Math.round(val * 100) / 100实现四舍五入。不适用Not Applicable审计会被强制清零权重另一个关键逻辑在scoreAllCategories中当某个审计的结果是notApplicable、informative或manual时Lighthouse 会把它的权重强制设为 0——它不会参与arithmeticMean的分子分母但仍然保留在最终 LHR 中并在报告中显示为“不适用Not Applicable”而不是拉低你的分数const result resultsByAuditId[member.id]; if (result.scoreDisplayMode Audit.SCORING_MODES.NOT_APPLICABLE || result.scoreDisplayMode Audit.SCORING_MODES.INFORMATIVE || result.scoreDisplayMode Audit.SCORING_MODES.MANUAL) { member.weight 0; }这些得分展示模式定义在 core/audits/audit.js 的SCORING_MODES静态属性中numeric、metricSavings、binary、manual、informative、notApplicable、error共七种。Performance 分数如何计算原文档指出Performance 评分的权威说明在 developer.chrome.com 的官方文章本仓库的职责是提供实现与权重配置。从源码看Performance 得分的计算由两部分组成第一各指标审计的权重。定义在 core/config/default-config.js 的performance类别| 审计 ID | 权重 | 说明 | |-|-|-| | first-contentful-paint (FCP) | 10 | 首屏内容绘制时间 | | largest-contentful-paint (LCP) | 25 | 最大内容绘制时间 | | total-blocking-time (TBT) | 30 | 主线程总阻塞时间 | | cumulative-layout-shift (CLS) | 25 | 累积布局偏移 | | speed-index (SI) | 10 | 速度指数 | | interaction-to-next-paint (INP) | 0 | 当前尚未纳入计分权重为 0 |第二每个指标审计自身的分数换算。审计的原始测量值毫秒通过对数正态分布换算为 0~1 的分数。以 first-contentful-paint.js 为例其defaultOptions中针对移动端和桌面端分别配置了两个控制点p10与medianmobile: { // 25th and 8th percentiles HTTPArchive - median and p10. scoring: { p10: 1800, median: 3000 }, }, desktop: { scoring: { p10: 934, median: 1600 }, },Audit.computeLogNormalScore依据“站点的 10% 分位数与中位数”这两个锚点构造曲线测量值优于median时得分不低于 0.5优于p10时得分不低于 0.9。这套机制意味着 Performance 分数是相对分布的——不是“跑进 3 秒就满分”而是与 HTTP Archive 全站统计数据对齐。Best Practices 分数如何计算原文档的结论非常简洁Best Practices 类别中所有审计权重相同因此每正确实现一个审计整体得分约提高 6 分。该结论对应的是早期等权计分的版本假如类别下有 N 个计分审计每个权重为 1则每个审计的贡献约为1/N换算成 0~100 分制大约就是文档所说的“每项约 6 分”即约 16 个计分审计。需要说明的是从当前仓库的 default-config.js 源码看Best Practices 类别的权重已经演变为差异化配置例如is-on-httpsHTTPS 支持权重 5deprecations已废弃 API权重 5third-party-cookies第三方 Cookie权重 5paste-preventing-inputs权重 3redirects-http、image-aspect-ratio、image-size-responsive、doctype、charset、errors-in-console、inspector-issues等权重 1csp-xss、has-hsts、origin-isolation、clickjacking-mitigation、trusted-types-xss、baseline、js-libraries、valid-source-maps等权重 0诊断性质不参与计分因此在实际使用中务必以你运行的 Lighthouse 版本对应的 default-config.js 中best-practices类别的实际权重为准而不是机械套用“每项 6 分”。SEO 分数如何计算原文档指出SEO 类别中除 Structured Data结构化数据外的所有审计权重相同Structured Data 是不计分的手动审计manual因此正确实现每个 SEO 审计约可提升 8 分。从当前源码 default-config.js 看这一结论依然成立且有一个值得注意的细节——is-crawlable页面可被搜索引擎抓取的权重被刻意设置为93 / 23约 4.04而不是 1。源码注释给出了设计意图Should be at least 31% of the score, such that this audit failing results in the SEO category failing.即is-crawlable单独失败就必须拖垮整个 SEO 类别因此其权重被求解为满足w / (w T) 0.31T 为其余审计权重之和。其余计分审计document-title、meta-description、http-status-code、link-text、crawlable-anchors、robots-txt、image-alt、hreflang、canonical权重均为 1而structured-data权重为 0属于手动审计需要人工确认后填写。Accessibility 分数如何计算与上述类别不同Accessibility 采用加权平均而非等权平均且每个审计都是**通过/不通过pass/fail**的二值审计——不存在“做对一半给一半分”的中间地带。权重从何而来axe-core 的 Impact 与 TagsAccessibility 类别的权重并非拍脑袋定的而是从 axe-core 规则的影响级别ImpactMinor / Moderate / Serious / Critical推导而来并参考其 Tags如wcag2a、wcag2aa、best-practice、experimental。映射表见 default-config.js 的注释| Impact | wcag AAA | best-practice | experimental | |-|-|-|-| | Minor | 1 | 0 | 0 | | Moderate | 3 | 3 | 0 | | Serious | 7 | 7 | 0 | | Critical | 10 | 10 | 0 |也就是说越严重、越符合 WCAG A/AA 标准的规则权重越高Critical 可达 10仅属于 best-practice 且非 WCAG 的规则通常不计分experimental 规则权重一律为 0。v7 时代的权重表原文档完整继承原文档给出了 v7 的具体权重百分比由底层权重 10 / 3 / 2 归一化后四舍五入得到总计约 98.4%与 100% 的差异来自小数舍入。逐项列出如下权重 4.1% 的审计16 项| 审计 ID | 权重 | |-|-| | aria-allowed-attr | 4.1% | | aria-hidden-body | 4.1% | | aria-required-attr | 4.1% | | aria-required-children | 4.1% | | aria-required-parent | 4.1% | | aria-roles | 4.1% | | aria-valid-attr-value | 4.1% | | aria-valid-attr | 4.1% | | button-name | 4.1% | | duplicate-id-aria | 4.1% | | image-alt | 4.1% | | input-image-alt | 4.1% | | label | 4.1% | | meta-refresh | 4.1% | | meta-viewport | 4.1% | | video-caption | 4.1% |权重 1.2% 的审计26 项| 审计 ID | 权重 | |-|-| | accesskeys | 1.2% | | aria-command-name | 1.2% | | aria-hidden-focus | 1.2% | | aria-input-field-name | 1.2% | | aria-meter-name | 1.2% | | aria-progressbar-name | 1.2% | | aria-toggle-field-name | 1.2% | | aria-tooltip-name | 1.2% | | aria-treeitem-name | 1.2% | | bypass | 1.2% | | color-contrast | 1.2% | | definition-list | 1.2% | | dlitem | 1.2% | | document-title | 1.2% | | duplicate-id-active | 1.2% | | frame-title | 1.2% | | html-has-lang | 1.2% | | html-lang-valid | 1.2% | | link-name | 1.2% | | list | 1.2% | | listitem | 1.2% | | object-alt | 1.2% | | tabindex | 1.2% | | td-headers-attr | 1.2% | | th-has-data-cells | 1.2% | | valid-lang | 1.2% |权重 0.8% 的审计2 项| 审计 ID | 权重 | |-|-| | form-field-multiple-labels | 0.8% | | heading-order | 0.8% |为什么 Accessibility 是“零和博弈”原文档特别强调Accessibility 的每个审计都是 pass/fail 二值判定。举例来说如果页面上一半按钮具备无障碍名称而另一半没有你得到的不是加权平均分的一半而是0 分——因为该审计要求整页所有按钮都必须正确实现。这意味着修复一个 4.1% 权重的审计失败比修复一个 1.2% 权重的审计对总分的影响大 3 倍以上但任何“只修复一半”的投入在二值审计下都等于零产出必须做到全量合规。如何在当前仓库重新生成权重表权重表并非硬编码的百分比而是由底层权重动态归一化得到。仓库提供了重新生成脚本 core/scripts/print-a11y-scoring.js按文档注释执行即可输出当前版本的权重百分比表格node core/scripts/print-a11y-scoring.js该脚本内部通过initializeConfig(navigation)加载导航模式的解析配置读取categories.accessibility.auditRefs用a.weight / sum * 100计算每个审计的百分比并降序排列输出。如果你关心的是当前仓库版本而非 v7的真实权重请直接查看 default-config.js 中 accessibility 类别的auditRefs——其中的权重值10 / 7 / 3 / 1与文档中的 v7 百分比表存在版本差异属于正常演进。从源码验证计分逻辑测试用例怎么说计分引擎的正确性由 core/test/scoring-test.js 覆盖理解这些用例有助于你反向确认机制等权计算三个权重均为 1 的审计得分取算术平均变权计算{score: 0.1, weight: 2}, {score: 0, weight: 7}, {score: 0.2, weight: 1}得到正确加权结果验证权重对总分的主导作用不适用审计权重归零将scoreDisplayMode设为notApplicable的审计权重强制为 0 后类别得分按剩余审计重新计算。这三点恰好对应实战中常见的困惑为什么某个失败审计几乎不动总分为什么有的审计显示“不适用”却没扣分答案都在 core/scoring.js 与 core/test/scoring-test.js 里。实战总结解读与提升 Lighthouse 分数的正确姿势先看权重再看颜色打开 LHR JSON定位 default-config.js 中对应类别的auditRefs优先修复权重最高且失败的审计。Performance 里 TBT(30)、LCP(25)、CLS(25) 是三大巨头Accessibility 里 4.1% 档的审计性价比最高。区分二值审计与数值审计Accessibility 全部是 pass/fail必须整页全量修复Performance 是对数正态分布分数存在“边际收益递减”接近 p10 控制点后再优化收益甚微。警惕“不适用”审计notApplicable、informative、manual三种模式的审计权重会被强制归零见 core/scoring.js它们不影响分数但会出现在报告中别被它们分散精力。以当前仓库源码为准本文中的 v7 权重表来自原文档而当前仓库的 default-config.js 已对 Best Practices、Accessibility 等类别做了权重演进。任何计分结论都应先核对所运行版本的实际配置必要时用node core/scripts/print-a11y-scoring.js重新生成权重表。理解计分机制只是第一步更完整的 LHR 字段解读可继续阅读仓库中的 understanding-results.md想了解如何按需裁剪审计与类别可参阅 configuration.md。【免费下载链接】lighthouseAutomated auditing, performance metrics, and best practices for the web.项目地址: https://gitcode.com/GitHub_Trending/lig/lighthouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考