做蜘蛛池的人常把注意力放在“蜘蛛来没来”上，却容易忽略下一個問题：它来了之後，有没有把頁面完整拿走。蜘蛛抓取是有時間预算的，响應太慢的入口頁，很可能只被抓到一半就断线，甚至直接被跳過。速度不是锦上添花，它决定了已發現的 URL 里有多少能真正完成抓取。
蜘蛛對响應時間的敏感度比人高
真實用戶遇到三秒白屏還會等，蜘蛛不會。抓取程序通常有连接超时和讀取超时两段预算，任何一段耗尽都會放弃目前請求。更麻烦的是，慢站点會拖累整個池子的抓取节奏：一個线程卡住，後面的 URL 就要排队，單位時間内能覆盖的入口頁數量随之下降。
各家搜尋引擎的超时阈值和判断逻辑並不公開，也不完全一致。不要按某個具体秒數去卡设計，把“越短越稳”当成方向即可。
入口頁慢，通常慢在這几處
- 首字节之前：DNS 解析、TLS 握手、CDN 回源、後端排队，這些都在蜘蛛拿到第一個字节前發生。
- 後端處理：動態查询資料库、調用外部接口、模板實时渲染，尤其是入口頁數量大、共用一個库的时候。
- 頁面内资源：外鏈的統計脚本、字体、第三方 JS，如果蜘蛛會执行脚本，這些都會延長整体耗时。
- 服務器负载：CPU 打满、磁盘 IO 饱和、内存不足換頁，都會让响應時間成倍上升。
- 缓存策略：该静態化的頁面還在實时生成，缓存命中率低，等于每個請求都從头算一遍。
別靠感觉，先把數字拿到手
很多池子出問题，是因為没人真的测過响應時間。可用的办法其實不少：
- 用 curl 看關键分段，重点看 time_starttransfer（近似 TTFB）和 time_total，多测几次取中位數，別只看一次。
- 看 access log 里的响應時間字段，如果日誌格式没带，先加上再谈優化。
- 按 UA 分组統計：蜘蛛請求和普通請求可能走不同的缓存路径，混在一起看會得出错誤结论。
- 分时段看，蜘蛛集中来訪的时段往往就是响應時間最長的时候。
超时、並發與响應時間是個三角
三者互相牵制。並發開得越高，服務器排队的請求越多，單請求响應時間越長，蜘蛛越容易超时；反過来，适度限制單 IP 並發、让請求快速得到响應，整体抓取完成量反而可能更高。
實践中的顺序通常是：先把入口頁尽量静態化或预生成，让绝大多數請求直接命中缓存；再對蜘蛛流量做單獨限流，避免它和普通用戶抢资源；最後才考虑加机器。跳過前两步直接扩容，成本高且治标不治本。
為了“快”而踩的几個坑
- 缓存返回空頁：缓存穿透或预热失敗时吐出空白 HTML，蜘蛛拿到的是没有内容的頁面。
- 错誤頁返回 200：出問题时统一返回 200 的提示頁，蜘蛛會把提示文字当成正常内容索引。
- 304 配置错誤：该给 304 的时候给了完整頁面，或者反過来给错，都會干扰蜘蛛對内容變更的判断。
- 只返回骨架：為了速度把正文改成纯 JS 渲染，蜘蛛不执行脚本时等于什么都没拿到。
- 砍掉所有外鏈资源却不检查渲染结果：頁面看起来快了，實际内容缺了半截。
一個可以照着做的顺序
- 先记錄現状：抓一份蜘蛛請求的响應時間分布，找出最慢的一批入口頁。
- 把這些頁做成静態文件或加一层缓存，確認缓存命中後响應時間下降。
- 给蜘蛛流量單獨限流，观察响應時間的波動是否收窄。
- 检查慢頁是不是共用了同一套模板或同一個慢查询，從源头改掉。
- 上线後持續看日誌，把响應時間当成日常巡检的一個固定指标。
速度解决的是“抓取完成率”，不是“抓取量”。把單頁响應压在一個稳定的区間内，再谈扩量，鏈路才不會越铺越堵。