网页加载速度优化：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2974a8afbd88.html
📄
网页加载速度优化：批量页面只有一部分被发现时怎样划分对照组
结论先行：如果批量页面里只有一部分被搜索引擎发现，而你要判断加载速度优化是否影响了发现率，对照组不应按“快/慢”划分，而应按“优化动作是否已经落地且可被独立验证”划分。具体说，先确认哪些页面已经完成速度改动、哪些还没动，再在这两类内部按模板、目录层级和内容类型配对。只有当未优化组和已优化组在这些维度上足够接近时，速度差异才值得作为解释变量；否则你看到的发现率差异更可能来自模板结构、内链位置或抓取预算分配。
先确认“被发现”和“被优化”是不是同一批页面
很多团队会默认：既然做了网页加载速度优化，被发现的页面自然应该更多。但发现率是一个抓取和链接层面的结果，速度只是其中一个可能因素。划分对照组前，先做一次交叉核对：
- 列出所有目标页面，标记每页的发现状态，例如是否出现在站点地图、是否有至少一个可抓取内链指向它、是否已被搜索引擎处理。
- 再标记每页的速度优化状态，例如是否已替换图片格式、是否已延迟非关键脚本、是否已调整首屏渲染路径。
- 把两张表合并，得到“已优化且被发现”“已优化但未发现”“未优化且被发现”“未优化但未发现”四类。
这个动作的结果会直接影响下一步：如果“已优化但未发现”和“未优化但未发现”数量都很大，说明发现瓶颈可能不在速度，而在链接入口或站点结构。此时继续按速度分组做对照，结论会失真。
对照组要按可比的页面单元配对，而不是按整站平均
批量页面之间往往不可比。一个商品详情页和一个帮助文档页，即使速度分数接近，被发现的机会也可能不同。更稳妥的做法是先把页面拆成可比的单元，再在单元内部划分对照组。
可用的配对维度包括：
- 模板相同：同一套页面模板生成的页面，DOM 结构和脚本依赖接近。
- 目录深度相近：距离首页的点击层级接近，避免把内链位置差异误判为速度影响。
- 内容类型一致：列表页、详情页、聚合页分开处理。
- 上线时间接近：老页面和新页面的抓取历史不同，混在一起会引入时间偏差。
假设一个例子：某站点有 400 个商品详情页，其中 120 个已完成图片压缩和脚本延迟，280 个未做。如果直接比较这两组的发现率，结论很可能被“已优化的 120 个恰好放在更浅目录”污染。正确做法是先在 280 个未优化页面中，找出与那 120 个在目录深度和模板上接近的页面，组成配对组。这样速度改动才是两组之间少数几个明显差异之一。
什么情况下速度可以作为主解释变量
只有满足以下条件时，才适合把速度优化当作发现率差异的主解释变量：
- 两组页面在模板、目录层级、内容类型和上线时间上基本匹配。
- 速度改动确实改变了可抓取内容的首屏呈现，而不只是实验室分数变化。
- 发现状态的变化发生在速度改动之后，且没有同时进行内链调整、站点地图重提或其他结构改动。
- 抓取日志显示，两组页面的抓取频次或抓取深度出现了可区分的变化，而不只是某一次统计归零。
如果这些条件不成立，速度优化仍然可能有效，但它不是当前发现率差异的可靠解释。此时应该把对照组重新按内链入口或目录层级划分，而不是继续加码速度测试。
一个会让结论失效的反例
反例：假设你按速度分组后，发现“已优化组”的发现率明显更高，于是决定全站推广。但后来发现，已优化组里有相当一部分页面同时被加进了首页推荐模块，而未优化组没有。这时发现率差异至少有三个合理解释：内链入口增加、抓取优先级变化、速度改动。仅凭现有分组无法区分。更麻烦的是，如果首页推荐模块只短暂存在，抓取量后续回落，也不能单独证明速度优化无效。这个反例说明：只要存在一个与速度改动同步发生的结构变化，原来的对照组就失效了。
下一步动作：先做最小配对，再决定是否扩大优化范围
实际可执行的动作是：从已优化页面中选出 20 到 30 个，再从同模板、同目录深度的未优化页面中选出数量相近的页面，组成最小配对组。记录两组在两周内的抓取频次、发现状态和首屏可抓取内容变化。如果配对组内出现方向一致的差异，再考虑扩大优化范围；如果没有差异，先检查内链和站点地图是否把未发现页面暴露给了抓取系统。这个动作的结果决定了下一步是继续做速度优化，还是先修复发现路径。
