很多抓取異常最後都會落到同一個原因上：服務器响應太慢。頁面本身没問题，robots 没拦，連結也在，但蜘蛛每次来都要等上几秒甚至超时，次數多了，来訪自然就少了。這篇文章整理一套以响應時間為切入点的自查方法，重点是量化和對比，而不是凭感觉说「好像有点慢」。
為什么响應時間值得單獨检查
蜘蛛對單個站点能同时發起的請求數是有限的，單次請求也不會無限等待。当响應時間從几百毫秒涨到两三秒，同样的時間窗口里能抓完的頁面數量會明顯下降；如果出現超时中断，這部分請求還會被记為失敗，蜘蛛後續可能主動降低訪問频次。所以响應時間不只是用戶体驗话题，它同时决定了抓取的吞吐量。
先分清几個容易混淆的指标
- 首字节時間（TTFB）：從請求發出到收到第一個字节，反映服務端處理速度，包含 DNS 解析、连接建立、應用逻辑、資料库查询等环节。
- 内容下载時間：首字节之後传輸完整 HTML 的耗时，和頁面体积、压缩方式、CDN 有關。
- 超时與 5xx 比例：比平均值更能說明問题，平均值很容易被大量正常請求稀释掉。
- 並發承载能力：單請求很快，但並發一上来就排队，同样會拖慢抓取。
- 静態頁與動態頁的差异：列表頁、篩選頁、带參數的頁面通常比文章頁慢，需要分開統計。
常见的拖慢原因
按排查成本從低到高，可以先看這几類：
- 資料库慢查询：列表頁或标簽頁在每次訪問时做全表掃描、模糊匹配；
- 同步調用第三方接口：頁面渲染时才去請求支付、推荐、天气等外部服務，對方一慢，整頁就慢；
- 動態生成图片或缩略图：每次請求都實时裁剪，且没有缓存；
- 日誌同步寫盘、調试開關未關閉：上线後仍開着详细日誌；
- 缺少缓存层：同一份資料每次訪問都要重新計算；
- DNS 解析與證书握手異常：首次连接耗时偏高，或證书鏈不完整導致反复重试。
一份可执行的自查清單
- 用 curl 或浏览器開發者工具，分別记錄首頁、栏目頁、詳情頁的首字节時間，取多次訪問的中位數；
- 在服務器日誌里按狀態碼和响應時間排序，找出最慢的那几十個地址，观察是否有共同特征；
- 單獨統計蜘蛛請求中超时和 5xx 的占比，並把 HTML 與静態资源分開看；
- 對比加缓存前後同一地址的响應時間，確認缓存命中的比例；
- 做一次简單的並發測試，確認站点在正常抓取强度下是否出現排队；
- 检查上线開關、調试模式、详细日誌是否遗留未關；
- 把结论整理成表格，隔一到两周复测一次。
记錄比單次测速更重要
單次测出的數字受網絡波動影响很大，容易出現「今天快了，明天又慢」的错觉。更實用的做法是固定几個采样地址和采样時間，把首字节時間、狀態碼、响應大小记下来，做成一條简單的時間线。站点改版、上新活動、調整缓存策略之後，對照這條時間线就能看出變化来自哪里。
响應時間不需要追求极致，只要稳定在一個合理区間、没有大量超时，抓取节奏基本不會被打乱。真正需要警惕的是突然變慢和持續變慢，而不是某個时刻的峰值。
最後提醒一句：响應時間是结果，不是原因。找到究竟是資料库、外部依赖還是缓存策略造成的，再决定怎么改，比盲目加机器更有效。