入口頁被蜘蛛抓到，只說明連結被發現了；能不能把内容完整交出去，還要看服務器在這几秒里的表現。蜘蛛的耐心比想象中短：一次請求如果迟迟没有响應，它往往直接断開，下次再来就是另一回事了。
蜘蛛對响應速度的容忍度
不同搜尋引擎的爬虫超时阈值不一样，常见做法是几秒到十几秒的连接與讀取超时。超過阈值，這一次抓取就作废。更麻烦的是，慢响應會被记錄成站点质量信号：同一批入口頁里如果有大量頁面需要十几秒才返回，蜘蛛的調度器會主動降低對整站的抓取频次，把額度挪给响應更快的站点。
真正影响抓取的三個數字
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 與本地缓存是否把動態請求又打回了源站。
- 調整後隔几天再看一次分布，避免只凭一次抽样下结论。
速度和容量是蜘蛛池里最容易被忽略的一环。资源接進来、連結铺出去之後，真正决定抓取效率的往往是這几個毫秒級的细节。把它当成日常监控的一部分，比事後反复猜测蜘蛛為什么不来要實在得多。