网站速度检测：只看成功页面会产生什么选择偏差
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7c5e167cb06.html
📄
网站速度检测：只看成功页面会产生什么选择偏差
只看成功页面做网站速度检测，最直接的选择偏差是：你测到的不是用户实际经历的加载分布，而是“能打开的那一批”的加载分布。失败、超时、被中断、部分资源未完成的访问被排除后，慢的样本往往恰好消失，因为慢本身就会增加失败概率。结果是速度结论系统性偏乐观，优化优先级也会排错。
两种条件下，成功页面的代表性完全不同
成功页面样本是否可用，取决于失败与超时在你站点上的发生机制。
- 条件一：失败主要是网络层瞬时抖动。用户网络短暂波动导致请求失败，重试后成功。此时成功页面样本与失败样本的加载特征接近，排除失败样本对速度分布影响有限，可以直接用成功页面的分位数做初步判断。
- 条件二：失败与页面本身重量相关。页面资源多、第三方脚本重、首屏依赖长任务，导致在慢设备或弱网下更容易超时或中途放弃。此时失败样本集中在大页面、重交互路径上，只统计成功页面等于把最需要优化的对象删掉了。
判断自己处于哪种条件，不需要复杂建模。把失败和超时按页面路径、设备类型、网络类型分组，看它们是否集中在少数几个模板上。如果集中，就属于条件二，成功页面样本不能代表全站。
选择依据：先看失败是否与页面特征相关
可核查的证据链比单一指标更有说服力。建议依次核对：
- 站内统计中，同一路径的成功访问与失败/超时访问，在设备类型和网络类型上的构成是否明显不同。
- 第三方估算流量与站内统计口径不同，前者通常按访问估算，后者按请求或会话统计，两者对“失败”的定义可能不一致，不要直接相减当作丢失量。
- 搜索引擎报告中的抓取或渲染失败，与真实用户失败不是同一口径，只能作为旁证，不能单独用来还原用户侧速度分布。
如果失败样本在慢设备、弱网、特定模板上占比更高，那么成功页面的速度分位数会低估真实用户的慢加载比例。此时继续只用成功页面排序优化项，会把资源投到本来就不慢的页面上。
实施动作：把失败样本纳入速度检测口径
一个可执行的动作是：在速度检测的采集环节，除了记录成功加载的耗时，同时记录未完成加载的原因分类，例如超时、资源加载失败、用户提前离开。对失败样本，不计算完整加载耗时，但保留其页面路径、设备与网络标签。
这个动作会改变下一步：当你按页面排序优化优先级时，可以先看“失败集中页”而不是“成功页里最慢页”。如果某个模板在失败样本中反复出现，即使它在成功页面里速度中等，也应优先检查它的资源依赖和首屏阻塞。
假设一个短例子：某列表页在成功样本中首屏耗时处于中位水平，但在失败样本中占比很高。此时若只按成功页面排序，它不会进入优化清单；纳入失败分类后，它成为优先检查对象。这个例子只用来说明比较方法，不代表任何真实站点数据。
例外与边界：什么时候可以暂时只看成功页面
成功页面样本并非永远不可用。以下情况可以暂时以成功页面为主：
- 失败率极低，且失败原因经抽查与页面特征无关，例如集中在少数已知的第三方不可用时段。
- 你当前的目标只是比较同一批成功访问下的相对快慢，用于发现明显异常页面，而不是估计全量用户体验。
- 失败样本缺少必要的页面标识，无法归因到具体模板，此时强行纳入只会引入噪声。
但要注意，请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能来自采集脚本变更、标签丢失、过滤规则调整。需要结合采集口径变化记录一起判断。
结论性选择
如果你的站点失败与页面重量、设备或网络相关，就应把失败样本的分类标签纳入速度检测，用它来修正优化优先级；如果失败主要是外部瞬时抖动且与页面无关，可以先用成功页面的分位数做相对比较，但要明确这只覆盖了“能打开”的那部分访问。两种选择的切换依据，是失败样本是否在页面维度上集中，而不是失败率数字本身。
