蜘蛛来到入口页，并不是一敲门就拿到内容。它要先建立连接，再等服务器吐出第一个字节，最后把整页读完。这三段里任何一段拖得太久，抓取都可能提前收场——蜘蛛转身走了，入口页后面链着的资源也就没机会被发现。
蜘蛛的三段等待
把一次抓取拆开看，时间花在三个地方：
- 建立连接：DNS 解析、TCP 握手、TLS 握手。如果入口页挂着不稳定的域名解析或证书链过长，这一步就会先吃掉几百毫秒。
- 等待首字节（TTFB）：请求发出去到服务器返回第一个字节。后端程序生成、数据库查询、同步调用外部接口，都堆在这里。
- 下载全文：首字节之后的传输时间。页面越大、出口带宽越紧，这一段越长。
对蜘蛛来说，这三段是连续的等待。它没有耐心一层层排查，只会在整体超过自己的容忍度时放弃。
超时不是一条固定线
不同搜索引擎、不同抓取模块的超时设置并不一样，也没有公开的统一标准。可以确定的是：越慢的入口页，被抓取的机会越少，抓取间隔也可能被拉长。与其去猜某条精确阈值，不如把思路放在“比同类站点更快”上。
几个常见现象值得注意：
- 首字节长期在几秒以上，蜘蛛往往连正文都没读完就断开。
- 页面明明不大，但传输阶段很慢，通常是服务器出口带宽被别的任务占满。
- 同一个入口页时快时慢，说明后端有不确定的耗时环节，比如按请求实时生成。
入口页为什么容易慢
蜘蛛池的入口页常有几个特征，正好都指向慢：
- 由程序批量生成的动态页，每次访问都要重新拼装。
- 为了“看起来内容丰富”，挂载了大量外部资源或统计脚本。
- 部署在配置较低的机器上，或者多个入口站挤在同一台服务器。
- 经过多层跳转，蜘蛛要跟着走好几次才能到内容。
这些做法在数量上省事，但在响应时间上会累积成负担。
怎么测，测什么
与其凭感觉，不如留下可比较的数字。命令行工具就能看到关键分段：
- 用 curl -w 输出连接时间、首字节时间、总时间，多测几次取中位数。
- 在 access log 里记录请求处理耗时，把入口页和普通页分开统计。
- 从不同网络位置测，避免只在自己办公室的网络上得到乐观结果。
建议按小时或按天对比，而不是只看一次结果。响应时间的波动，往往比平均值更能说明问题。
可落地的优化顺序
先砍不确定性
- 入口页尽量静态化，把拼装工作放到生成阶段，而不是每次访问时。
- 去掉页面上非必要的外部请求，尤其是同步加载的第三方脚本。
- 减少重定向层数，能让蜘蛛一次拿到的，就不要让它走两趟。
再补基础设施
- 给入口页单独准备一份缓存，命中缓存时直接返回。
- 检查 DNS 与证书配置，缩短握手环节的等待。
- 如果多个入口站共用一台机器，给抓取请求留出带宽余量。
最后才是扩容
加机器、加带宽能缓解压力，但如果前端还在实时生成、还在堆外部资源，扩容只是把同样的问题推到更大的池子里。先把结构性的耗时降下来，再看资源是否够用。
一个容易被忽略的点
响应时间不只影响“这次能不能抓到”，还影响蜘蛛对入口页更新节奏的判断。一个长期秒回的入口页，蜘蛛更愿意多来几次；一个经常超时的入口页，即使内容真的更新了，也可能要等很久才被发现。
把入口页的响应时间当成一项日常指标来观察，比事后翻日志找原因要省力得多。
简单说，蜘蛛在门口等待的时间是有限的。你不需要做到极致快，但要避免让它站在那儿，面对的是一扇迟迟不开的门。