不少站点的問题不是“打不開”，而是“打開得慢”。运营看頁面觉得還行，但蜘蛛拿到的是一次次漫長的等待：請求發出後，服務器要過一两秒才開始吐第一個字节。抓取预算有限，等待時間越長，能真正被讀到的頁面就越少。所以服務器响應時間值得当成一項常規自查，而不是等出事故才處理。
先確認慢在哪一段
响應慢不一定是服務器本身的問题，從請求到内容返回，中間有好几段路。排查前先分段看，避免一上来就重啟服務、加配置。
- DNS 解析：解析耗时是否稳定，換解析商或加 TTL 不当都可能带来波動。
- 连接與 TLS 握手：新建连接慢、證书鏈過長、未啟用會话复用，都會拉高首字节。
- 服務器處理：這是最常见的一段，程序执行、資料库查询、模板渲染都算在内。
- 传輸與回源：回源鏈路抖動、反向代理排队，也會让蜘蛛感觉“站点很慢”。
用命令行工具可以直接看到分段耗时。例如用 curl -w 輸出 time_namelookup、time_connect、time_appconnect、time_starttransfer、time_total 這几項，连續跑十几次取中位數，比單次结果更有參考價值。浏览器開發者工具的網絡面板、以及服務器訪問日誌里的响應時間字段，也是常用来源。關键是對同一批頁面反复采样，而不是只看首頁一次。
服務器端最常见的几類原因
- 資料库慢查询：列表頁、标簽頁、搜尋頁最容易中招，缺索引或一次性取大量資料會明顯拖慢。
- 重复計算：每次請求都重新拼装相同的区块，比如热门文章、侧栏推荐，没做缓存就每次重算。
- 外部調用同步阻塞：頁面渲染时同步請求第三方接口，對方一慢，整頁跟着慢。
- 進程與资源不足：應用進程數過少、内存吃紧、磁盘 IO 打满，請求排队後表現為首字节變長。
- 後台任務抢资源：备份、日誌切割、批量導入如果和抓取高峰重叠，很容易造成时段性變慢。
一套可以照做的排查顺序
- 先在一天内分时段采样，区分“一直慢”和“某個时段慢”，這直接决定排查方向。
- 對比静態頁與動態頁：如果静態文件很快、動態頁面慢，問题基本在後端處理。
- 打開慢查询日誌，按耗时排序，看是否有反复出現的同類语句。
- 检查缓存命中情况，包括頁面缓存、對象缓存、字节碼缓存，命中率低往往就是主要瓶颈。
- 逐個確認外部依赖的耗时和超时設定，找不到明顯的單点，就繼續用二分法缩小范围。
几處性價比高的改動
- 给高频被抓取的頁面加頁面缓存，比如栏目首頁、文章頁，让重复請求直接命中缓存。
- 给所有外部請求設定明确的超时和降級方案，超时後返回占位内容，而不是一直挂着。
- 把不常變但計算量大的内容，從“請求时算”改成“生成时算”。
- 把 sitemap、robots 等蜘蛛高频訪問的文件做成静態文件，不走完整應用流程。
- 調整後台任務時間窗，避開蜘蛛活跃时段，减少资源争抢。
监控和告警要看的指标
只看平均值容易被少數极慢請求掩盖，建议關注 P95、P99 這類分位值，並按小时留存记錄。可以在服務器日誌中提取响應時間字段，做成简單趋势图；当某個分位值连續一段時間超過自定阈值时再触發告警。阈值不必追求很低，重点是“稳定且可预期”，避免今天 200 毫秒、明天 3 秒的剧烈波動。
响應時間的目标不是越快越好，而是可预期。稳定的首字节時間，能让蜘蛛更愿意按計划走完你的頁面。
最後提醒一句：優化响應時間属于基础设施层面的改善，它能减少無效等待、让抓取更顺畅，但並不會直接带来收錄或排名上的承诺。把它当作日常维護的一部分，定期采样、定期复盘，比临时抱佛脚更有用。