先明确决策，再选择工具
在运行任何工具之前，先给出有风险的页面、受众和要保护的任务：例如移动产品页、结账页或潜在客户表单。然后选择证据类型。实验室数据是在受控环境下用于可重复调试的测试。现场数据是用于优先级排序的真实用户聚合体验。浏览器跟踪有助于解释本地运行时的工作量。这些是互补的，而非可互换的。
询问是什么阻止访客完成一项重要任务，而不是如何获得一个分数。
在添加更多产品之前，先使用一次审计、可用的现场数据和一个诊断工具。
结果适用于被测试的 URL、条件或样本；它并不代表对每位访客的最终判决。
用 Lighthouse 和 PageSpeed Insights 做可重复的页面加载审计
Lighthouse 是一个开源的自动化审计工具，可在 Chrome DevTools 中、本地命令行或持续集成里运行。它审计性能、无障碍、SEO 等方面。PageSpeed Insights 会对一个 URL 运行 Lighthouse 诊断，并在可用时呈现真实用户数据。用任一工具对具有代表性的页面建立基线，调查未通过的审计项，并在定义好的改动后进行受控复测以比较差异。
在其测试设置下被审计页面的行为，以及哪些审计项值得进一步调查。
良好的 Lighthouse 分数并不一定意味着真实用户体验良好；Google 文档说明了实验室数据和现场数据可能存在差异。
在变更后对相同页面和相同设置进行复测；不要把它当作一次性的门槛。
使用现场数据为真实用户的体验确定优先级
PageSpeed Insights 的现场数据来自 Chrome User Experience Report，覆盖最近 28 天。它报告的指标包括 Largest Contentful Paint、Interaction to Next Paint 和 Cumulative Layout Shift。Search Console 的 Core Web Vitals 报告在你需要关注一组页面而不是单个 URL 时很有用。用现场数据来决定哪个模板、设备组或问题应当先行投入。
检查结果是页面级还是来源级，以及该 URL 是否有足够的数据。
现场数据具有历史性并经过隐私聚合，因此不能立即确认一次发布的即时效果。
Google 推荐 LCP 在 2.5 秒以内，INP 低于 200 毫秒，CLS 低于 0.1。
当审计需要解释时使用 Chrome DevTools
当审计或现场模式指出加载缓慢、交互延迟或视觉位移时，在 Chrome DevTools 的 Performance 中记录整个过程。它记录 CPU 配置文件，并能显示本地 LCP、CLS，以及交互后（或在交互过程中）的 INP。其时间线有助于开发人员调查浏览器的实际工作，而不是仅凭推荐列表猜测原因。
使用与受影响受众相近的视口、CPU 和网络条件。
一次跟踪反映了所记录的设备、连接、缓存状态和路径。在泛化结论之前重现相关旅程。
记录怀疑原因、拟议改动及预期对访客的影响。
将自动化无障碍检查与有经验的人工评估配对
使用无障碍评估工具可以及早并反复发现可机检的问题。W3C WAI 维护工具清单和选择指南，但说明单一工具无法判断站点是否满足无障碍标准。用自动化结果建立审查队列，然后由合格评审人员检查代表性页面、键盘操作、焦点行为、错误处理和内容。
更快地发现并防止可重复出现的缺陷。
无法判定全面的无障碍合规性，也不能替代人工评估。
不要将自动化结果作为法律合规的证明；在需要时取得合格的无障碍和法律评审。
在授权范围内谨慎使用针对性的安全工具
Mozilla 的 HTTP Observatory 检查 HTTP 头和其他关键安全配置，为面向公众的头部卫生提供起点。在生产环境之外验证拟议的头部更改，因为策略可能影响脚本、嵌入服务和用户流程。它评估的是安全的一部分，而非应用的所有风险。
OWASP ZAP 可以被动扫描流量并对应用进行主动测试，但只能测试你被授权测试的系统。
ZAP 提醒主动扫描是一种真实攻击，可能给目标带来风险。被动扫描可能漏掉需认证或未访问的区域。
对于支付、认证、敏感数据或重大发现，应当让合格的安全专业人员参与。
把工具输出转为 SIU 的修复流程，而不是追分
采用经久的闭环流程：捕获基线、识别一个合理的原因、做最小的安全改动、对相同路径复测，并在足够时间后观察现场趋势。将访客任务置于中心。缩减阻塞性资源只有在不破坏购买、登录、无障碍、用户同意或分析行为的前提下才有意义。
偏好有现场影响、可复现跟踪或明确面向用户的缺陷支撑的改动。
使用预发布环境、负责人、验收标准和回滚计划。SIU 有助于防止可避免的体验降级。
在变更记录里保留指标、测试条件和完成的访客任务，而不只是分数。