响應時間為什么值得單獨盯着
蜘蛛来一個頁面，要先建立连接、等服務器返回第一個字节，再把整頁讀完。這三步里任何一步卡住，都會占着它的连接和配額。搜尋引擎给一個站点的抓取量並不是無限的，服務器慢，蜘蛛往往就會降低来訪频次——這不是惩罚，而是它把時間挪去別處了。所以响應時間是运营的基础項，地基不稳，内容和结构做得再好也容易打折。
先分清是服務器慢還是頁面大
- TTFB（首字节時間）：服務器處理一個請求要多久。
- 完整下载時間：首字节之後，把 HTML 传完花多久。
- 连接阶段：DNS、TCP、TLS 握手的耗时。
- 狀態碼分布：5xx、超时、连接重置各占多少。
如果 TTFB 高但下载很快，問题多半在服務端；如果 TTFB 正常却下载慢，那更可能是 HTML 体积或带宽的問题。两個方向的處理手段完全不同，先分清再動手，能省下不少無用功。
不用复杂工具也能自查
- 用命令行對一個典型 URL 計时，连續跑几次，看波動幅度。
- 浏览器開發者工具的網絡面板，看每個阶段的耗时分布。
- 翻服務器訪問日誌，筛出蜘蛛的 UA，按响應碼和耗时排序。
- 把同一批 URL 放在不同时段對比，区分偶發和常態。
只看首頁是不够的。首頁往往挂了缓存，栏目頁和詳情頁才是真實水平。
常见的几類原因
- 資料库慢查询，列表頁每次請求都要重新聚合一遍。
- 没做頁面缓存或對象缓存，每個請求都走完整逻辑。
- 應用冷啟動，進程被回收後第一批請求特別慢。
- 共享主机上被邻居抢占资源，表現时好时坏。
- 定时任務、备份、日誌切割正好撞上抓取高峰。
- 大文件和動態頁面放在同一环境里互相挤带宽。
處理的先後顺序
先加缓存，通常是性價比最高的一步；再優化最耗时的查询和循环；然後考虑把稳定不變的頁面静態化，或把静態资源交给 CDN；最後才是升級配置。顺序反過来，钱花了不少，效果却未必明顯。
關于蜘蛛池的一点說明
蜘蛛池解决的是引導蜘蛛来訪的問题，解决不了来了之後服務器扛不扛得住。如果响應本来就慢，拉来更多請求只會让情况更糟，日誌里 5xx 的比例也會往上走。這两件事應当分開看：先把站点自身的响應打理好，再谈引流與發現。
把它變成日常動作
- 關键頁面加监控，超過阈值就告警。
- 小改動之後就复测，別等到下一次大改版。
- 看 5xx 和超时的趋势，而不是某一天的孤立數值。
- 记錄每次調整前後的資料，方便回溯原因。
响應時間是那種平时不出声、出問题时很棘手的基础項。它不需要天天折腾，但值得有一個固定的观察位置。