先不要急着改代码或换服务器。确定影响范围的核心方法是:用同一套测量条件,把“异常”拆成可对比的维度——哪些页面、哪些用户、哪些地区、哪些设备、什么时间段、哪个指标变差。只有先圈定范围,才能判断是局部问题还是全局问题,以及下一步该查前端、网络还是后端。
要确定影响范围,至少需要三类资料。第一类是基线数据:异常发生前一段时间的加载性能记录,最好包含不同页面模板和不同设备的数值。第二类是异常期数据:同一批页面在同一测量条件下的当前表现。第三类是分层标签:页面所属模板、用户地区、网络类型、设备类型、访问来源。没有基线,就无法判断“变慢”是真实退化还是正常波动;没有分层标签,就只能看到整体平均值,容易掩盖局部严重问题。
如果暂时没有现成监控,可以用浏览器开发者工具或命令行工具手动采样。采样时固定网络条件、设备模拟和测试位置,否则对比没有意义。
把异常按以下维度逐层拆分,每层记录“正常/异常”的判断结果:
判断规则可以这样用:如果异常只出现在一个模板且所有地区都受影响,优先查该模板的代码和依赖;如果只有某个地区异常而所有模板都受影响,优先查网络链路或 CDN 节点;如果只有移动端异常,优先查图片和脚本。注意,同一现象可能有多个解释,比如“某地区变慢”既可能是 CDN 节点问题,也可能是该地区运营商路由变化,需要进一步对比同地区不同网络的结果。
分层之后,做一次最小对比实验。步骤是:
这个实验能帮你区分“页面自身问题”和“访问环境问题”。适用条件是:你有至少一个可对比的正常样本。如果所有页面都异常,就跳过页面对比,直接对比异常前后同一页面的数据。
以下检查项会影响你对范围的判断,需要逐项确认:
关于 robots.txt、站点地图和 HTTPS,这里需要分清:robots.txt 的抓取限制不等于可靠的索引移除;站点地图不保证收录;HTTPS 不保证安全无漏洞或排名提升。这些和加载速度异常的范围判断没有直接关系,不要把它们当成速度问题的解释。
当你已经能回答“哪些页面、哪些用户、哪个指标、从什么时候开始异常”,就把这个范围写成一句话,例如“移动端用户访问商品详情模板时,首字节时间从某时间点开始变长,桌面端和其他模板正常”。然后带着这句话去查对应环节:模板问题查代码和依赖,地区问题查网络和 CDN,接口问题查服务端日志。范围越具体,排查越省力。