@addyosmani 发布了Web质量审计Skill，基于Lighthouse，对Web质量进行全面审计，值得一试。
@addyosmani 发布Web质量审计Skill，基于Lighthouse，涵盖性能、可访问性、SEO等五个维度，提供五步工作流程和四大设计理念。
Web 质量审计 Skill：web-quality-audit 来自 @addyosmani「Web Quality Skills」，给 Agent 注入一套 Lighthouse 风格的 Web...
Web 质量审计 Skill：web-quality-audit 来自 @addyosmani 「Web Quality Skills」，给 Agent 注入一套 Lighthouse 风格的 Web 质量审计方法论，覆盖五个维度：性能、可访问性、SEO、最佳实践、智能体浏览。 # 工作流程（五步） 1. 确定审计目标：代表性 URL、关键状态与用户旅程、公开/登录态、移动端/桌面端范围。 2. 采集实时基线：页面可运行时，先做一次 trace + 一次 Lighthouse 审计，不做大范围代码扫描。 3. 以运行时证据定位源码：实测失败点 → 定向源码检查。 4. 按用户影响与置信度分级，给出或执行具体修复。 5. 复测验证：同条件重跑自动化检查与受影响的手动流程，明确报告"已验证什么、什么仍待现场或人工确认"。 # 核心设计理念 一套 "测量认识论"——明确规定了什么算证据、每种工具能证明什么、不能证明什么。四条基本原则： 1. 证据优先于分数。 聚合分数（如 Lighthouse 总分）只是诊断摘要，其权重随版本变化，不能作为质量的证明。真正的证据是指标数值本身（LCP、INP、CLS 的具体读数）。 2. 先实测，后读码。 只要页面能运行，必须先采集最小化的实时基线，再做源码审查；用运行时失败来定位源码问题，而不是反过来。实测结论与仅从代码推断的假设必须严格分开标注。 3. 证据类型分层，不可混淆。 · CrUX 现场数据：真实 Chrome 用户的 28 天滚动聚合（p75） · 一方 RUM：站点自己采集上报的真实会话 · DevTools 性能 trace：特定条件下的单次实验室会话 · Lighthouse 实验室跑分：受控合成导航 · 静态代码检查：纯推断 4. 可复现性纪律。 记录完整测量条件（URL、页面状态、视口、网络/CPU 节流、缓存冷热、登录态）；关键结论至少跑 3 次取中位数并报告区间；单次本地 trace 不得直接与 CrUX p75 对比。 # 五大审计维度要点 性能：核心 Web 指标硬门槛——LCP < 2.5s、INP < 200ms、CLS < 0.1；外加资源优化（图片 WebP/AVIF、代码分割、关键 CSS、字体 font-display: swap）与加载策略（preconnect、preload、懒加载、长缓存）。 可访问性：按 WCAG 四原则（可感知/可操作/可理解/健壮）展开，对比度 AA 级 4.5:1（大文本 3:1）、键盘可达、焦点可见、表单标签关联等。 SEO：可抓取性（robots、sitemap、canonical）、页面要素（唯一标题、描述、链接文本）、技术项（移动友好、HTTPS、结构化数据）；措辞克制——用 CWV 现场数据作证据，不承诺排名变化。 最佳实践：安全（HTTPS/HSTS/CSP、无漏洞依赖、生产环境不暴露 source map）、现代标准（无废弃 API、控制台零报错）、UX 规范（无侵入式插页广告）。 智能体浏览（前瞻性新类目）：以语义化 HTML 和无障碍树暴露程度衡量 AI 代理对页面的理解与交互能力；WebMCP 存在时须校验但不鼓励为刷分而加；llms.txt 可选。明确与 SEO 切割——可代理性不构成搜索排名或 AI 可见性的证据。 # 工具路由与降级策略 首选 Chrome DevTools MCP（performance_start_trace 记录 trace → performance_analyze_insight 只分析可疑洞察；lighthouse_audit 跑其余四类——它有意不含性能）。降级路径依次为：Lighthouse CLI → PageSpeed Insights → CrUX Vis → 静态检查。不因缺少可选工具而阻塞审计。另有一条务实的 token 节约原则：先文本快照后截图、大报告落盘只摘 actionable 项、按需钻取少数关键洞察。 # 输出规范与分级 问题按四级定级：Critical（安全漏洞、完全失效 → 立即修）、High（CWV 不达标、重大无障碍障碍 → 上线前修）、Medium（性能机会、SEO 改进 → 迭代内修）、Low（次要优化 → 择机修）。 报告结构强制以证据表开头（信号 / 范围与条件 / 结果 / 来源），随后按严重级列出问题（每条含影响、证据类型、具体修复），最后给出优先级排序与验证状态（同条件复测结果、人工检查项、仍待现场验证项）。 github.com/addyosmani/web… 💬 2 🔄 1 ❤️ 6 👀 952 📊 6 ⚡