网站加载速度，批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ba4c57ad9da2.html
📄
网站加载速度，批量页面只有一部分被发现时怎样划分对照组
先给出结论：不要按“已发现”和“未发现”直接分组，而要先按页面模板、资源依赖和抓取入口三个维度建立可比对照，再把“是否被发现”当作结果而不是分组依据。否则你比较的其实是不同模板或不同入口的差异，而不是加载速度本身的影响。
先确认你手中的资料能支持哪种分组
假设你手里有一份站点地图和一份服务器访问日志，日志中记录了每个URL的响应时间、状态码和抓取时间。你需要先做一件事：把两份资料按URL对齐，标出每个页面属于哪个模板、依赖哪些公共资源、通过哪个入口被链接。如果某个模板下的页面全部集中在同一批入口，那么这个模板和入口就是混杂的，不能直接作为分组变量。
判断依据是：如果同一模板的页面既有被发现也有未被发现的，说明模板本身不是决定因素，可以继续看资源依赖；如果同一模板的页面全部未被发现，那么模板和发现状态无法分离，此时应换一个维度，比如按页面深度或按是否被站内搜索引用。
按模板和资源依赖建立两组可比页面
具体动作：从已发现页面中选出与未发现页面同模板、同主要资源、同层级深度的页面，组成对照组A；再从已发现页面中选出同模板但不同资源版本的页面，组成对照组B。对照组A用来观察“发现状态”是否伴随加载速度差异，对照组B用来观察“资源版本”是否独立于发现状态产生影响。
结果如何影响下一步：如果A组和未发现组在加载速度上差异明显，而B组内部差异很小，那么优先检查资源加载链路；如果A组差异不明显，而B组差异明显，那么优先检查资源版本切换的时间点是否与抓取行为变化重合。这里的关键是，对照组必须共享至少一个变量，否则比较没有意义。
用抓取入口而不是页面列表来划分时间窗
很多批量页面问题不是同时发生的。你需要按抓取入口划分时间窗：站内链接入口、站点地图入口、外部链接入口。假设站点地图提交后，一批页面在三天内被集中抓取，而站内链接入口的页面是分散抓取的。此时如果把所有已发现页面混在一起，加载速度的均值会被集中抓取那批拉低或拉高。
可执行的做法是：对每个入口分别计算已发现页面的加载速度分布，再与同入口下未被发现页面的速度分布比较。如果某个入口下两者分布重叠，说明该入口不是区分因素；如果某个入口下两者分布分离，说明该入口的抓取行为可能受加载速度影响。注意，这只是相关性，不能直接推断因果，因为入口本身可能同时影响抓取频率和页面类型。
一个注明假设的短例子
假设某站点有200个商品页，其中80个被发现，120个未被发现。按模板分，这200个页面共用同一套模板；按资源分，其中60个页面引用了旧版图片压缩脚本，140个引用了新版脚本。如果你直接比较已发现和未发现，发现旧版脚本页面在未发现组中占比更高。此时应建立两个对照组：第一组只比较同用旧版脚本的已发现与未发现页面；第二组只比较同用新版脚本的已发现与未发现页面。如果第一组差异大、第二组差异小，那么下一步应优先排查旧版脚本的加载行为，而不是继续扩大抓取提交范围。
把结论转成下一步动作
完成分组后，你至少应得到一个可执行判断：是继续调整加载速度，还是先修复入口或资源版本。动作可以是：对差异最大的那组页面，单独记录其资源加载耗时和抓取响应状态，观察后续一周内发现状态是否变化。如果变化只出现在该组，说明你的分组有效；如果所有组同步变化，说明外部因素在起作用，需要重新划分对照组。站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除，因此分组结论只能用于指导排查顺序，不能替代对具体入口和资源路径的逐项核查。
