入口页被蜘蛛抓到，只说明链接被发现了；能不能把内容完整交出去，还要看服务器在这几秒里的表现。蜘蛛的耐心比想象中短：一次请求如果迟迟没有响应，它往往直接断开，下次再来就是另一回事了。
蜘蛛对响应速度的容忍度
不同搜索引擎的爬虫超时阈值不一样，常见做法是几秒到十几秒的连接与读取超时。超过阈值，这一次抓取就作废。更麻烦的是，慢响应会被记录成站点质量信号：同一批入口页里如果有大量页面需要十几秒才返回，蜘蛛的调度器会主动降低对整站的抓取频次，把额度挪给响应更快的站点。
真正影响抓取的三个数字
TTFB（首字节时间）
从蜘蛛发起请求到收到第一个字节的时间，包含了 DNS、建连、TLS 握手以及服务端的处理。入口页本身通常很轻，TTFB 却偏大，多半是程序里做了同步的外部调用，或者每次请求都要查数据库、拼模板。把入口页做成静态文件或加一层页面缓存，往往比换更贵的服务器更有效。
页面体积与传输
蜘蛛读取的是 HTML，不是渲染后的画面，但体积仍然影响抓取。一个入口页塞进几十 KB 的冗余脚本、内联样式和 base64 图片，会拖长读取时间，也会让正文和链接的位置往后挪。入口页的价值在链接和承接，建议把 HTML 控制在几十 KB 以内，脚本样式外置并压缩，图片交给懒加载或不放。
连接稳定性与超时设置
服务端如果设置了很短的执行超时，或者 Nginx、PHP-FPM 的连接数上限偏低，蜘蛛并发一上来就会出现 502、504。这类错误在日志里表现为响应时间很短但状态码异常，容易被误判成“蜘蛛没来”。反过来，服务器超时设得过长，蜘蛛已经放弃，你的进程还在占着资源，高峰时更容易雪崩。
实际可以做的几件事
- 入口页尽量静态化，避免每次请求都走完整框架初始化。
- 开启 gzip 或 brotli 压缩，HTML 文本的压缩比通常很可观。
- 把统计、广告、推荐接口改成异步加载，不阻塞首屏 HTML 输出。
- 为入口页单独设定较短的超时与较宽松的并发限制，和后台接口分开。
- 用同一台机器上的多个入口页做对比测试，确认瓶颈在程序还是在网络。
别只看“抓了多少次”
日志里能看到的字段通常包括状态码、响应时间、返回字节数和 User-Agent。只看抓取次数很容易得出乐观结论：次数在涨，但平均响应时间从 300ms 涨到 2s，返回字节数掉了一半，说明抓取质量在下降。把响应时间分布和成功返回的比例一起看，比总数更有参考价值。
抓取频次不是越高越好。让每一次抓取都能在几百毫秒内拿到完整的 HTML，比让蜘蛛多来几百次更有意义。
排查顺序建议
- 先在日志里筛出响应时间超过 1 秒的入口页请求，看是否集中在某台机器或某个模板。
- 再核对状态码，区分 5xx、超时和正常的慢响应，三者的处理方式不同。
- 检查返回字节数是否稳定，突然变小可能是模板报错或缓存返回了空页。
- 确认缓存命中率，尤其是 CDN 与本地缓存是否把动态请求又打回了源站。
- 调整后隔几天再看一次分布，避免只凭一次抽样下结论。
速度和容量是蜘蛛池里最容易被忽略的一环。资源接进来、链接铺出去之后，真正决定抓取效率的往往是这几个毫秒级的细节。把它当成日常监控的一部分，比事后反复猜测蜘蛛为什么不来要实在得多。