蜘蛛抓取是有成本的。同一個站点，服務器响應快，蜘蛛在同样時間里能多取几十上百個頁面；响應慢，抓取队列就會往後排，新内容上线後可能迟迟不被訪問。很多站点内容本身没問题，卡点却在服務器端——每次請求要等一两秒才吐出第一個字节。
為什么响應速度會直接影响抓取
搜尋引擎爬虫通常會為每個站点分配一定的並發數和超时阈值。当請求長時間没有响應、或者频繁超时，爬虫會主動降低對该站的抓取频率，避免把资源耗在一個慢站上。抓到一半断開、只取到部分内容的情况，也會让頁面被判定為不稳定。
抓取预算不是固定的配額，它更像一個随响應质量浮動的信用額度：响應稳定快速，額度就宽裕。
先量出真實的首字节時間
TTFB（Time To First Byte）指從發出請求到收到响應第一個字节的時間，它包含了 DNS 解析、连接建立、服務器處理、後端渲染等环节。要判断問题出在哪儿，得把這几段分開看。
几個常用的测量方式
- 浏览器開發者工具的 Network 面板，看每個請求的 Waiting（TTFB）一列，注意区分平均值和個別頁面。
- 命令行用 curl 輸出各阶段耗时，例如 curl -o /dev/null -s -w '%{time_starttransfer}' URL，可以批量跑几個有代表性的頁面。
- 服務器訪問日誌里的响應時間字段，能看出慢請求集中在哪些路径、哪些时段。
- 监控工具按小时采样，比一次性测速更能反映真實波動。
测的时候要区分「只有動態頁面慢」還是「整站都慢」。如果只有带查询參數的頁面慢，問题多半在後端；如果连静態图片都慢，可能是带宽、DNS 或前置鏈路的問题。
常见的拖慢原因
- 資料库缺少合适索引，列表頁每次都要全表掃描。
- 頁面渲染时同步調用外部接口，第三方一慢，整頁就卡住。
- 未開啟頁面缓存或缓存命中率低，同一份内容反复計算。
- 單台服務器扛全部流量，爬虫和真實用戶互相抢资源。
- 日誌同步寫入频繁，磁盘 IO 被打满。
- 图片或附件未压缩，出口带宽被大文件占满。
可以按這個顺序優化
- 先加一层頁面缓存，把不常變的列表頁、詳情頁缓存几十秒到几分钟，收益通常最直接。
- 给高频查询字段补索引，尤其是列表排序和時間篩選用到的字段。
- 把第三方調用改成异步或加超时與降級，避免一個接口拖垮整頁。
- 静態资源交给 CDN，服務器只處理動態請求。
- 如果已经被爬虫高频訪問，可以在 robots.txt 或服務器层面對低價值路径限流，把资源留给正文頁。
- 最後再考虑升級配置，顺序反了容易花了钱没解决問题。
優化之後怎么驗證
不要只看某一次测速變快了。至少观察一到两周：服務器日誌中的中位响應時間是否下降，抓取總量和新增頁面的被訪問速度是否回升，超时和 5xx 是否减少。如果响應時間下降但抓取量没變化，說明瓶颈可能在別處，比如内鏈入口太少或站点地图没有覆盖新頁面。
另外注意別走到另一個极端：為了压低 TTFB 把缓存時間设得過長，導致内容更新後訪客長時間看到舊頁面；或者缓存粒度過粗，把不同用戶的狀態混在一起。速度是手段，稳定和内容准确才是目的。