Site Speed · 从测量到有依据的变更
从问题的最初迹象到安全变更：为什么需要 Speed Snapshot、Diagnostic Audit 与 Sprint
较低的 PageSpeed 评分或明显变慢的网站，确认了问题的存在，但尚未回答两个关键问题：为什么会发生，以及哪些变更是安全的。
本文展示了 Speed Snapshot、Diagnostic Audit 与 Sprint 之间的区别，以及为什么更深层的干预，只会在已经获得充分依据之后才会开始。
当网站运行缓慢时，第一反应很自然：找到问题并立即修复。
PageSpeed Insights 给出较低的评分，Lighthouse 标记出延迟——看起来只剩下确定具体要改什么了。
但在发现的症状与对一个正在运行的网站进行安全变更之间，存在几个不同的问题：
究竟发生了什么？
为什么会发生？
真正值得改变的是什么——干预本身是否合理？
因此，从最初的测量到实施之间的路径被划分为几个决策：
Speed Snapshot → 如有需要进行 Diagnostic Audit → 决策 → 若有充分依据，则进入 Sprint。
每个阶段的存在并非为了流程本身，而是为了避免在尚未获得充分依据之前，就采取代价更高、风险更大的行动。
可见的问题尚不能说明究竟需要修复什么
性能测量可以很快确认网站确实存在问题。
主要内容出现得太晚。服务器返回首个响应的速度太慢。JavaScript 明显加重了页面负担。较大的资源延迟了内容的呈现。
这已经是有用的信息。
但同一个外部表现，可能源于不同的原因。
服务器响应慢，并不一定意味着托管服务不好。原因可能在于应用程序本身、缓存、外部依赖、配置，或者同时涉及其中多个环节。
第三方 JavaScript 造成较高负载，也不意味着可以直接删除该脚本。它可能与统计分析、广告、Cookie 同意系统、支付，或其他重要功能相关。
因此，以下两种表述：
"我们看到了一个问题"
与
"我们知道需要改什么"
之间存在本质区别。
对正在运行的系统进行的干预越严重，就越需要先理解原因及其可能带来的后果。
Speed Snapshot 能带来什么
Speed Snapshot 是第一层检查。
它让你可以基于现有可获得的测量数据审视网站，在不深入介入系统的情况下，形成一个初步的整体判断。
由此可以更清楚地了解：
- 测量数据中真正能看到哪些问题；
- 这些问题出现在哪些页面上；
- 相同的迹象是否重复出现；
- 哪些结论已经得到确认；
- 哪些问题需要更深入的诊断。
Snapshot 的主要价值，并不在于自动生成一份工作清单。
它应当回答一个更前置的问题：
是否存在已确认的问题，公开数据是否足以支撑下一步决策？
如果没有确认存在实质性问题，可能并不需要进一步深入诊断。
如果问题可见，但公开数据不足以理解其原因和安全的变更路径，这就构成了进行 Diagnostic Audit 的依据。
公开测量的能力边界在哪里
PageSpeed Insights、Lighthouse 以及其他外部工具，有助于发现重要信号，但无法揭示网站的内部构造。
例如，如果测量显示服务器首次响应耗时较长，可以确认延迟本身确实存在。但要回答"为什么"，往往已经需要关于应用程序运行方式、缓存、数据库、外部依赖或基础设施的数据。
页面加载也是如此。从外部可以看到某个资源加载较晚，或某个脚本造成较大负载。但并不总能看出它承担什么角色、与什么相关联，以及变更之后会发生什么。
还存在另一个边界：单个页面的结果，并不一定能代表整个网站。首页、目录页、产品页、申请表单和个人中心，可能有着不同的结构，也可能源于不同的变慢原因。
因此，初步测量有助于缩小排查范围，但无法取代原因层面的诊断。
何时需要 Diagnostic Audit
公开测量能够很好地展示症状，但并不总能让人看清系统内部的构造。
当问题不再只是：
发生了什么？
而变成：
为什么会发生，真正值得改变的是什么，改动又会带来哪些风险？
这时就需要 Diagnostic Audit。在这个阶段，任务是将观察到的症状与真实的原因、限制条件和后果关联起来，并理解从这些变更中现实可期待的结果是什么。
诊断并不一定要以 Sprint 收尾
在 Diagnostic Audit 之后，可能出现几种正常的结果。
可以进入 Sprint
原因已经足够清晰，变更有充分依据，风险处于可接受范围之内。
需要先做准备
变更是有意义的，但在实施之前，需要先具备安全工作的条件：测试环境、可用的回滚方案、额外的访问权限，或消除另一项限制。
目前 Sprint 并不成立
预期的改善，相对于干预的规模可能过小，或者对正在运行系统的风险过高。
需要另一条路径
用更聚焦的变更、对系统的准备工作，或更深层的技术方案来解决问题，可能更为合理。
因此，一次好的诊断结果，并不意味着必然要确认未来的 Sprint。
它是一个关于接下来该做什么——以及不该做什么的有依据的决策。
为什么 Sprint 只有在获得充分依据后才会开始
Sprint 已经在改变一个正在运行的系统。
在这个阶段，仅仅知道网站慢是不够的。需要理解：
- 哪个原因已被确认；
- 哪项变更与该原因相关；
- 还有哪些方面可能受到影响；
- 结果将如何被验证；
- 如果变更产生了不希望出现的效果，该如何限制风险。
没有这些，很容易在改善一个指标的同时，制造出一个新的问题。
可以改变资源的加载顺序，却让页面的另一部分变差。可以关闭 JavaScript，却破坏了统计分析或某项面向用户的功能。可以改动缓存策略，却带来数据新鲜度方面的问题。
因此，Sprint 不应是在生产环境网站上的一次实验，而应是对一个已有充分依据的计划的受控执行。
如果所需的答案很快就能获得，那么到实施为止的路径也可以很短。但被缩短的是获得依据所需的时间，而不是安全性方面的问题本身。
从最初信号到决策的路径是怎样的
实际的流程保持简短：
Speed Snapshot → 如有需要进行 Diagnostic Audit → 决策 → 若有依据，则进入 Sprint。
Speed Snapshot 展示了通过现有测量数据能够确认什么，以及是否需要更深入的分析。
当外部数据已不足以支撑判断时，Diagnostic Audit 用于确定原因、限制条件与风险。
在此之后，才会做出决策：实施变更、先对系统进行准备、选择另一条路径，或就此停止。
这样的顺序，并不是为了增加环节的数量。它的作用，是让审查的深度与下一步行动的代价相匹配。
从哪里开始
如果你对网站的性能有疑问，第一步并不需要预先判断到底需要 Audit 还是 Sprint。
网站本身，以及几个最重要的页面或场景，就已经足够。
可以从 Speed Snapshot 开始。
它将展示：
- 当前的测量数据真正能够确认什么；
- 问题出现在哪里；
- 是否存在进行更深入诊断的依据；
- 或者目前是否并不需要进一步的干预。
核心原则始终简单：
下一步行动越严重，在开始之前就越需要充分的依据。