入口页铺得再多，蜘蛛每次来只做一件事：发请求、等响应、决定要不要继续。响应慢，它不会投诉，只会降低来访频率，把抓取预算挪到别的站点。所以响应速度不是一个“性能问题”，而是入口页能不能被持续抓取的前置条件。
蜘蛛的等待是有上限的
搜索引擎爬虫对单次请求的等待时间通常有几秒到十几秒的超时阈值，各家数值不同，也不会对外公开。你不需要记住精确数字，只要理解一件事：当服务器响应超过这个阈值，这次抓取就算失败。失败次数累积到一定程度，调度端会认为这个站点不稳定，把抓取配额往下压。
这个过程是渐进的，不会一次性给你惩罚。所以很多人是在日志里看到蜘蛛请求数慢慢变少，才回头去找原因。
TTFB 比“页面打开速度”更关键
不少人看的是页面完全加载时间，但蜘蛛判断快慢的主要依据是首字节时间，也就是从发出请求到收到第一段响应的时间。图片、CSS、JS 这些资源一般不影响它对入口页 HTML 的判断。
- TTFB 在几百毫秒内：基本不会成为问题
- 1～2 秒：偶尔可以，长期如此容易被降频
- 超过 3 秒：失败率上升，多线程抓取时更明显
需要说明的是，这些只是经验区间，不是官方标准。不同爬虫、不同时段、不同机房线路，表现都会有差异，最终还是要以自己站点日志为准。
哪些“慢”是假慢
很多入口页本身是静态的，却依然很慢，问题往往出在链路而不是内容：
- DNS 解析慢：解析服务不稳定，或者 CNAME 层级堆得太多
- TLS 握手慢：证书链不完整、不支持会话复用、强制跳转层数过多
- 回源慢：CDN 缓存命中率低，每来一个请求都回源到后端
- 后端慢：入口页动态生成时查库、调接口、等外部服务
- 出口拥塞：同一台机器上站点过多，带宽被其他业务占满
排查时建议先用命令行工具分别测 DNS、建连、TLS、首字节这几段，定位到具体环节再改，不要一上来就动代码。
比“慢”更麻烦的是错误响应
超时只是让蜘蛛等，5xx 和 429 会让它直接判定失败。入口页里如果有一批 URL 长期返回 500、502、503，或者因为限流频繁返回 429，影响会扩散到同一域名下的其他页面。
- 出现 5xx 先查应用日志，确认是偶发还是持续
- 429 要谨慎使用，蜘蛛被限流后不会立刻恢复到原来的频率
- 连接被重置、半开连接，表现和超时接近，但更难被发现
几项可以实际动手的调整
不需要做很复杂的事，先把最影响响应时间的环节处理掉：
- 入口页尽量静态化或加一层缓存，避免每次请求都走动态渲染
- 把入口页和重业务站点分开部署，避免互相抢 CPU 和连接数
- 给蜘蛛来源留出单独的连接数和带宽，但不要用极端规则直接拦截
- 监控按状态码分组的响应时间，而不是只看整体平均值
别把速度优化做成另一场军备竞赛
响应速度是基础条件，不是效果保证。入口页能在合理时间内返回正常内容，蜘蛛愿意持续来访，这就够了。如果把精力全投在毫秒级优化上，却忽视页面质量、链接关系和重复度，收益通常不成比例。
判断标准其实很简单：看日志里蜘蛛请求的成功率和频率趋势，而不是看某个体检测试工具的分数。分数好看但蜘蛛不来，说明真正的问题不在速度上。