入口页能被抓，不代表蜘蛛愿意抓完。同样一批 URL，响应快的那组往往被抓得更深、更频繁；响应慢的那组，蜘蛛可能发几个请求就撤了。这一层的调优通常不需要改内容，只需要盯住几个服务器指标。
先分清三个时间
讨论快慢之前，先把耗时拆开，否则很容易误判：
- 网络往返：蜘蛛机房到服务器之间的物理延迟，主要由线路和地理位置决定，跨境线路差异尤其明显。
- 服务端处理时间：程序执行、数据库查询、模板渲染加起来的时间，这是你能改的部分。
- 传输时间：HTML 体积除以可用带宽，页面越大、带宽越挤，这段越长。
三个数加起来才是蜘蛛感知到的等待。很多人只盯程序耗时，结果页面里塞了大量内联脚本和外链资源，蜘蛛依然等得久。
TTFB 大概什么水平算正常
不给绝对值，给一个可操作的判断方法：把入口页的 TTFB 和自己的一张纯静态页做对比。
- 接近静态页：说明动态开销已经压住，这个状态可以接受。
- 明显高于静态页，但仍在几百毫秒量级：常见情况，通常还能用，重点看波动幅度。
- 经常超过一秒，或者忽快忽慢：值得排查，此时抓取深度和频次往往会下滑。
比平均值更值得关注的是尾延迟。10% 的请求要等三五秒，比全部请求稳定在五百毫秒更糟，因为蜘蛛的调度对超时相当敏感，一次超时可能就让整个抓取计划提前结束。
超时阈值：服务器、中间层、蜘蛛三处要对齐
一个请求可能被三处超时掐断：
- Web 服务器的连接保持与请求读取超时，例如 Nginx 的 client 系列参数；
- 后端应用或数据库的连接与执行超时；
- 蜘蛛自身的抓取超时。
常见问题是只调了其中一层。比如 Nginx 给 60 秒，应用默认 30 秒，数据库 10 秒，蜘蛛最终拿到的往往是一个 500，而不是完整页面。建议从外到内逐层收窄：外层最长，内层略短，让内层先失败并返回明确状态，而不是让外层硬等。
别让蜘蛛撞上静默等待
比超时更麻烦的是连接已建立、却迟迟不返回任何字节。蜘蛛在这种状态下通常不会无限等，反复遇到之后可能降低对该站点的抓取频次。如果后端确实慢，宁可快速返回 503 并带上重试提示，也不要挂着不动。
并发与限速：入口页不只有蜘蛛在访问
入口页往往同时承受蜘蛛抓取、监控探测和少量真实访客。如果服务器不做区分，一次蜘蛛的并发抓取就可能把工作进程占满，后续请求全部排队，尾延迟随之飙升。可考虑的做法：
- 给入口页加短时缓存，让绝大多数请求不落到动态程序上；
- 按 UA 或 IP 段给蜘蛛单独限速，而不是全局一刀切；
- 把入口页与后台接口分层部署，避免互相抢占连接数；
- 观察工作进程占用与队列长度，而不是只看 CPU 使用率。
排查清单
- 用同一台境外机器分别测入口页和一张纯静态图，对比 TTFB；
- 看日志里的响应时间分布，统计超过一秒的请求占比；
- 检查是否存在外层超时大于内层超时的情况；
- 确认 HTML 体积，尤其首屏之外是否有大段无用代码；
- 确认蜘蛛请求是否与普通访客共用同一套限速规则；
- 对比调整前后的蜘蛛抓取请求数，用数据判断是否真的改善。
响应速度不是玄学，它是一条能被日志量化的曲线。多数时候，把尾延迟压下来，比把平均值再降五十毫秒更有价值。
小结
入口页的响应速度属于基础设施层面的问题，改起来见效相对直接：拆清耗时来源、收紧内层超时、给蜘蛛单独限速、盯住尾延迟。做完这几件事，再回头看抓取深度和频次的变化，才谈得上判断有没有起作用。