法国独立开发者 Théo Ducreux 对 Tranco 排名前 5000 的网站做了一次规模化检查：成功抓取到可读内容的 2656 个网站中，87.2% 至少存在一处 HTML 规范违规，完全没有 HTML 错误的网站只有 12.8%。如果把 best-practice 警告也算进去，结果会更加严格。
这组数据不代表“网页已经无法使用”，却揭示了一个容易被忽略的事实：Web 标准仍然支撑着浏览器、搜索引擎、辅助技术和开发工具，但在真实生产页面中，规范符合度往往不是团队的优先级。
标准没有消失，只是被工程目标挤到后面
现代网站通常同时承载前端框架、营销组件、广告脚本、分析代码、A/B 测试和第三方小部件。页面能在主流浏览器中显示出来，往往就被视为“完成”。
问题在于，浏览器对错误 HTML 很宽容。它们会尝试修复标签嵌套、容忍重复属性，甚至在结构不完整时继续渲染页面。浏览器的容错能力让错误暂时不影响视觉效果，却也降低了团队修复问题的紧迫感。
规范校验关注的不是页面截图是否正常，而是文档结构和语义是否可靠。例如：
- 标签是否正确闭合和嵌套；
- 属性是否符合 HTML 语法；
- 元素是否被放在允许的位置；
- CSS 语法和属性值是否有效；
- 页面是否违反某些可维护性或最佳实践规则。
因此，“浏览器里看起来没问题”和“页面符合规范”是两个不同的判断。
这次统计说明了什么
这项检查使用 html-validate 和 csstree-validator，对抓取到的页面分别进行 HTML 与 CSS 校验。样本从 Tranco 排名前 5000 的网站开始，但最终只有 2656 个网站成功抓取并获得了可读内容，所以结论应理解为这批可分析样本的统计结果，而不是整个互联网的精确抽样。
核心数字很清楚：
- 2656 个网站成功进入分析范围；
- 87.2% 至少存在一处 HTML 规范违规；
- 12.8% 的网站没有 HTML 错误；
- 如果将 best-practice 警告也视为问题，完全干净的网站比例会进一步下降。
这里最值得关注的并不是某个站点是否出现了一个拼写错误，而是规范检查与日常开发流程之间存在断层。许多团队会检查 TypeScript、单元测试、依赖漏洞和构建产物，却未必会在 CI 中检查最终 HTML 和 CSS。
可以把网页校验接入 CI
如果项目已经使用 Node.js，可以先安装两个校验工具。下面是一个可以改造到项目中的最小示例，假设待检查的文件位于 dist/index.html 和 dist/app.css：
npm install --save-dev html-validate csstree-validator
npx html-validate dist/index.html
npx csstree-validator dist/app.css
也可以在 package.json 中增加脚本，让本地检查和 CI 使用同一条命令：
{
"scripts": {
"validate:web": "html-validate dist/index.html && csstree-validator dist/app.css"
},
"devDependencies": {
"html-validate": "latest",
"csstree-validator": "latest"
}
}
运行：
npm run validate:web
实际项目通常需要根据框架产物调整路径。例如，服务端渲染应用应检查构建后生成的 HTML；静态站点可以遍历整个输出目录。不要只检查手写的模板，因为组件组合、模板编译和插件注入都可能改变最终文档。
一个更稳妥的落地方式是分阶段处理：
- 在本地和 CI 中先记录错误，不立即阻断所有构建；
- 修复高频、低风险的结构问题，例如未闭合标签和重复属性；
- 将新增违规设为构建失败，避免问题继续增长；
- 对第三方注入内容单独统计，不要把外部脚本的问题混入业务代码指标。
不要把校验器当成唯一质量标准
规范校验很有价值，但它不能替代完整的 Web 质量检查。一个没有 HTML 语法错误的页面，仍可能存在键盘无法操作、表单缺少标签、对比度不足、加载缓慢或移动端布局失效等问题。
相反，校验器报告的每一项也不一定都值得立刻修复。旧浏览器兼容策略、第三方组件、构建工具生成的属性，以及特定业务场景，都可能需要例外。团队应该区分三类结果：
- 必须修复：会破坏 DOM 结构、影响解析或导致明确的兼容性问题；
- 建议修复：提升语义、可访问性或长期维护性；
- 有意保留：有明确原因，并且被记录和复查。
这次大规模统计更像一面镜子，而不是一张及格线。它提醒我们，Web 标准没有因为框架和工具链的发展而变得不重要；恰恰因为页面越来越复杂，稳定的 HTML 和 CSS 基础更需要自动化守护。
给团队的实践清单
可以从一次小范围改造开始：
- 选择一个核心页面作为校验试点；
- 检查构建后的最终 HTML，而不是只检查源模板；
- 将 HTML、CSS 校验加入预发布流程；
- 记录违规来源、负责人和是否属于第三方内容；
- 先阻止新增错误，再逐步清理历史债务；
- 把校验结果与可访问性、性能和浏览器兼容性检查结合起来。
当一个页面“能显示”不再等同于“质量合格”，Web 标准才会重新回到工程流程里。它不需要成为团队每天手工核对的负担，但应该成为构建系统能够持续检查的基础约束。