做站点运营时，大家习惯盯着内容和連結，但頁面能不能被顺利抓取，很多时候卡在更前面的一环：服務器响應速度。爬虫是按队列工作的，一個地址的响應没有結束，它很难痛快地轉向下一個。如果單頁動辄几秒，甚至超时断開，抓取效率就會明顯下降，原本能被發現的頁面也可能被排到很後面。
先確認慢在哪一段
用 curl 的耗时輸出或浏览器開發者工具的時間线，把一次請求拆開看：DNS 解析、TCP 连接、TLS 握手、等待首字节（TTFB）、内容传輸。多數站点的瓶颈在 TTFB，也就是服務器真正開始吐資料之前的等待。如果 TTFB 就占了两三秒，後面传得再快意义也有限。
值得留意的几個指标
- TTFB：最能反映後端處理效率，通常優先關注；
- 總耗时：包含内容下载，頁面越重差异越明顯；
- 狀態碼分布：偶尔冒出 5xx 或超时，說明稳定性存在問题；
- 並發下的表現：單次請求快，不代表同时来几十個請求還快。
也可以横向對比：首頁快、詳情頁慢，問题多半出在业務逻辑；静態文件快、動態頁慢，常和資料库或缓存有關；移動端和桌面端都慢，則更可能是服務器整体负载偏高。
常见的拖慢原因
- 詳情頁每次請求都查库，且没有做頁面級缓存或查询缓存；
- 渲染时同步調用第三方接口，接口一慢整頁跟着慢；
- 會话、統計、推荐等逻辑在首屏阻塞执行；
- 服務器 CPU、内存、磁盘 IO 長期接近上限，高峰期排队；
- 带宽或出口有限，大文件把连接占满；
- 防火墙、WAF、限流規則對爬虫請求做了額外延迟或拦截。
抓取预算不是無限的
搜尋引擎给每個站点分配的抓取资源是有限的。响應快、更新稳定的站点，單位時間里能抓更多地址；响應慢的站点，同样的時間只能覆盖很少的頁面。時間一長，新内容進入索引的速度會變慢，一些深层頁面可能長期排不上队。
與其反复提交 Sitemap 催促，不如先把 TTFB 從三秒压到几百毫秒，效果往往更直接。
可以按這個顺序排查處理
- 先建立基线：连續几天记錄首頁、栏目頁、詳情頁的 TTFB 和總耗时，区分高峰期與低谷期。
- 關掉不必要的同步調用，把統計、推荐、评论加载改成异步或延後执行。
- 给詳情頁加缓存，热点内容走内存或静態化，减少重复查库。
- 检查慢查询日誌，给常用查询补上索引，避免全表掃描。
- 静態资源交给 CDN，减轻源站的带宽和连接压力。
- 核對服務器的限流與安全策略，確認正常爬虫不會被誤伤或刻意延迟。
- 設定超时兜底，避免個別請求長時間挂起占用连接。
把它變成日常监控項
响應時間适合做成長期指标，而不是出問题才去看。可以用简單的定时脚本或监控服務，按分钟或按小时记錄關键頁面的狀態碼和耗时，超過阈值就告警。观察时注意区分：是偶發抖動，還是持續變慢；是全部頁面，還是某一類頁面。前者可能是临时负载，後者往往指向具体的代碼或查询。
需要提醒的是，調優的目标是让頁面稳定、及时地返回内容，而不是追求某個绝對數字。不同站点的架构差別很大，先找到自己的瓶颈，再一点点改，比一次性大改更稳妥。