评分方法

我们会真正在 Chromium 中加载您的页面——两次，一次是限速的手机档位，一次是电脑档位——然后采集与 Lighthouse 相同的指标，并用它的官方曲线打分。同时，HTTP 响应头会经过 Mozilla Observatory 的评分表，无障碍则由 axe-core（Lighthouse 所用的引擎）分析。

每个维度得出一个百分制分数，总分是它们的加权平均。

测量条件。手机档位：视口 412 × 823，网络限制为 1.6 Mb/s、150 毫秒延迟——即 Lighthouse 的「Slow 4G」预设——CPU 降速 4 倍。电脑档位：1350 × 940，不限速。报告总分采用手机档位，与 Google 的做法一致。

我们观察多长时间。我们会等待网络静默，最长十秒。在 2026 年 8 月 14 日之前，这个上限是三秒，它会把较慢的页面截断：在 gouvernement.fr 上，我们记录到的最大内容渲染是 1.6 秒，而 Lighthouse 测得 25.6 秒——只是我们过早地闭上了眼睛。放宽上限会让较慢页面的检测多花约两秒，对其余页面则毫无影响，它们远在上限之前就已静默。

未测量 Speed Index，因为它需要逐帧分析加载过程的录像。与其凭空编一个数值，我们选择剔除它占的 10% 权重，并在剩余的 90% 上重新归一化。每份报告都会写明这一覆盖比例。

宣称「兼容」却不给数字，等于什么也没说。因此我们在一批公开网站上，把自己的分数与 Lighthouse 默认设置（即 PageSpeed Insights 所用设置）下的分数作对照。以下为 2026 年 8 月 11 日、手机档位的记录：

在轻量到中等的页面上，差距在 0 到 5 分之间。在需要执行大量 JavaScript 的页面上，2026 年 8 月 14 日之前差距曾达到 12–24 分；原因是我们自身工具的两处缺陷，现均已修复。

我们自己的安全防护扭曲了测量结果。为防止网站通过重定向让我们去请求内网地址，我们会在每个文档请求上暂停，先完成一次校验。这次校验只需 9 毫秒——但暂停导航会让 Chromium 无法启动预加载扫描器。在 gouvernement.fr 上实测：首次渲染变成 15.0 秒，而不是 1.6 秒。产生差分数的是工具，而不是网站。该防护现在改为「观察式」，不再暂停任何请求。

真实限速与模拟限速。我们是真正降低 CPU 与网络速度，然后观察结果。Lighthouse 默认是在不限速的情况下加载页面，再用算法模拟劣化条件。两种做法都合理，但测量的并非同一个量，而且差距恰恰在需要执行大量代码的地方被拉大。

Lighthouse 自身的波动也很大。在同一个较重的页面上，条件完全相同的三次连续 Lighthouse 运行分别给出 47、65、66 分。在这类页面上追求五分以内的一致，等于在追逐噪声。真正需要吻合的是各项细分指标和数量级，而不是小数点。

反过来，如果在一个轻量页面上与 PageSpeed Insights 出现较大差距，那多半是我们这边的问题。欢迎向我们反馈：正是通过这种方式，我们发现了一处会让完美页面白白损失多达 27 分的测量缺陷。

分数从 100 分起算，每项测试按 Mozilla 的公开评分表加分或扣分：没有 Content-Security-Policy 扣 25 分，没有点击劫持防护扣 20 分，缺少 HSTS 扣 20 分，会话 Cookie 未带 Secure 标志扣 40 分，第三方脚本经 HTTP 加载扣 50 分；反之，采用 default-src 'none' 的 CSP 加 10 分，具有保护性的 Referrer-Policy 加 5 分。总分随后换算为 A+ 至 F 的等级。

有三项 Observatory 测试超出我们的能力范围，我们在每份报告中都会标明，而不是把它们当作通过：跨源资源共享（CORS）、HSTS 预加载列表的实际收录情况，以及 TLS 证书链的有效性。

直接从公共 DNS 读取，并通过一次 TLS 握手获取：IP 地址、域名服务器、MX 与 CAA 记录、证书到期时间与颁发机构、协商使用的 TLS 版本，以及 SPF、DMARC 和 DKIM。不向网站发送任何内容，也不修改任何内容。

这些检查针对的不是被检测的页面，而是域名本身：一张八天后到期的证书，或一个没有 DMARC 的域名，实际造成的代价远高于几分性能分。

两处如实承认的局限。只有当域名发布了邮件服务器（MX）时，我们才要求 SPF 与 DMARC：对不接收邮件的域名提出这些要求属于误报。另外，DNS 无法列出 DKIM 选择器：我们只测试最常见的一批，因此没找到并不能证明 DKIM 不存在——报告中会明确说明这一点，而不是草率下结论。

分析在渲染后的页面上进行，即 JavaScript 执行之后：对比度是真实计算出来的，ARIA 角色也已解析，这些都是阅读 HTML 源码做不到的。所采用的规则为 WCAG 2.0 与 2.1 的 A、AA 级。

分数是通过规则所占的比例，而不是做减法：以通过的规则数，除以该数加上未通过规则的权重之和（严重违规计 2，较严重计 1，中度计 0.5，轻微计 0.25）。

为什么要改，以及它修正了什么：此前的评分标准是每条问题扣固定分值。在内容稍多的网站上，扣分总和会超过 100，分数直接归零——lemonde.fr 得了 0/100，而它 36 条已评估规则中有 26 条是通过的。2026 年 8 月 13 日与真实 Lighthouse（手机）的对照：lemonde.fr 在 Lighthouse 为 68，旧标准 0，新标准 67；ovhcloud.com 为 72 / 15 / 77；我们故意做差的演示页面为 89 / 75 / 88；fr.wikipedia.org 为 96 / 85 / 94。平均差距从 37.5 分降到 2.3 分。

仍然存在、我们如实说明的差异：Lighthouse 对每条规则单独加权，用的是一张约上百条目、且随版本变化的权重表；而我们依据的是 axe 公布的影响级别。引擎相同，但加权更粗糙。

此外，自动化检测本身也只能覆盖真实无障碍的一部分——大致是 RGAA 准则的三分之一。键盘导航、替代文本是否贴切、阅读顺序是否合理，都需要人工测试。

RGAA 4.1 准则。每条问题都会对应到具体准则，附上法国 DINUM 所发布标准中的官方编号与原文条目。旁边还会显示 WCAG 级别（A、AA）及对应的 WCAG 准则编号。在非法语版本中，条目文字是便于理解的参考译文，界面上也会注明：具有法律效力的文本仍是法文版，真正作为引用依据的是编号。

我们给自己定的规矩：凡是归属取决于上下文的规则，一律不给编号。一个缺少无障碍名称的按钮，若用于操作某个组件则属准则 7.1，若用于提交表单则属 11.1；随意二选一会让无障碍声明失真，而这份声明是对发布者具有约束力的公开文件。这类问题只保留其主题分类，不再多写。

我们会单独显示一个比率：在机器可判定的准则中，已满足的比例，约为一百零六项中的二十五项。它不是 RGAA 合规率，这一点就写在数字旁边，PDF 中也是如此——若把这个百分比单独抄进招标文件，就成了谎言。

无法自动判定的准则会连同操作方法一并列出；当测量结果给出值得警惕的线索时，它们会被提到前面：出现正数 tabindex，说明 Tab 顺序可疑；存在没有标签的字段，说明现有标签是否贴切也值得怀疑。

最后，我们会按 DINUM 的格式生成一份无障碍声明草稿：承诺、结果、无法访问的内容、申诉途径。其中的合规状态留空待填，绝不代为填写——仅凭自动化测试就下结论，会让这份声明失实。

每条无障碍问题都会附上每个出错元素的 CSS 选择器、其标记内容，以及在所提供文档中的行号（如果能找到）。查找是在浏览器实际收到的那份文档中进行的，而不是我们抓取程序取回的那份：很多服务器会根据 User-Agent 返回不同内容，否则就会在错误的文本里找行号。

结果只有三种，绝不制造虚假精度：确切行号、大致行号（元素是通过某个标志找到的，渲染时属性顺序已改变），或者根本没有行号——要么因为所提供的 HTML 被压缩成了一行，要么因为该元素由 JavaScript 生成。后两种情况，报告会说明是哪一种。

常见缺陷会附带「修改前 / 修改后」的修复方案。只有当转换是机械且完整的，才会标注「可直接粘贴」；一旦某个属性值为了显示而被截断，它就退回为模板——粘贴被截断的代码会让页面出错。

优先级综合了严重程度、受影响元素数量和预估工作量：加一个属性只需一分钟，重做一套配色则要设计师参与。可导出的整改方案按此顺序列出全部条目，每条都附上位置、代码和验证方法。

这一维度不再阅读源代码，而是直接观察。页面在真实浏览器中加载，并且不点击任何内容——不接受任何横幅，不关闭任何弹窗。因此报告随后列出的一切，都是在未取得同意的情况下获得的：这正是让结论具备证据效力、而非停留在「可能」的原因。

记录的内容包括：实际连接的域名、实际写入的 Cookie 及其有效期、写入本地存储的键名，以及是否出现同意弹窗——我们也会在 iframe 和 shadow DOM 中查找，因为市面上多数同意管理平台把它放在那里。Cookie 分为三类：已识别的追踪器、严格必要（会话、购物车、防 CSRF、防机器人、同意记录——即法国监管机构认可的豁免项），以及无法判定。来源不明的第三方 Cookie 绝不会被归入「必要」一类。

欧盟境外传输：我们会识别每个被连接域名背后的运营机构及其适用法律。因此我们确认的是接收方，而不是其服务器的实际所在地——这一区别会写进报告，因为它会改变可以据此得出的结论。

法律声明：我们会从首页跟进法律声明链接，并逐项查找法国 LCEN 与商法典要求的十二项内容——名称、注册资本、注册地址、工商登记号、增值税号、联系方式、出版负责人、主机服务商及其联系方式、个人数据、Cookie、知识产权。该检查基于文本：它只能发现缺失，不判断已写内容是否准确。并且只对可能适用法国法律的网站启用。

如果浏览器无法运行，本维度会退回到读取 HTML，粒度要粗糙得多——报告会如实说明，而不会让您误以为那是真实观察结果。要断言一个网站「符合 GDPR」，必须审查其数据处理活动，而这是任何自动化工具都做不到的。

该分数采用 Green IT 组织的公开算法，也就是 ecoindex.fr 所用的算法：只有三个量——文档节点数、请求数、传输体积——先换算为在参考总体中的位次，再加权。文档占总分一半，请求占三分之一，体积占六分之一。分位数和公式均原样取自参考实现，以便我们的分数能与其结果相比。

这三个量来自为性能测试已经完成的那次加载：绿色评分不会额外增加一次请求或一秒钟。所显示的排放量（每次访问的二氧化碳当量克数与水的厘升数）来自该评分的官方函数，而非我们自行估算。

这个分数没有涵盖的内容：它只评估页面本身的精简程度，仅此而已。它不考虑您的主机服务商、服务器所用电力结构，也不考虑网站的真实访问量。它是设计层面的指标，不应与碳足迹报告混为一谈。

这三个维度基于对所提供文档的检查：title 与 meta description 是否存在及其长度、Open Graph 标签、标题层级、robots.txt 与站点地图、规范链接、所声明的语言、viewport 元标签、文档类型声明、内联样式与内联事件处理器。

分数从 100 起算，每条问题按严重程度扣分：严重扣 22 分，高扣 14 分，中扣 8 分，低扣 4 分，仅提示扣 1 分。与前面三个维度不同，这是我们自定的评分标准。GDPR 维度采用同一标准，但有一处例外：其中的提示项不扣分，以便完全没有追踪器的网站确实能得 100 分。