聊蜘蛛池时，大家习惯把注意力放在入口頁數量、互鏈结构和跳轉方式上，却很少問一個更基础的問题：蜘蛛来一次，拿到你的頁面需要多久。抓取是有成本的，蜘蛛的並發连接數、單次抓取的時間预算都有限，一個响應慢的入口頁占住的资源，本来可以分给別的頁面。所以速度不是锦上添花的優化項，它直接决定單位時間内能有多少 URL 被發現。
蜘蛛眼里的“慢”是什么
從蜘蛛發出請求到拿到完整响應体，中間有好几段耗时：DNS 解析、TCP 连接、TLS 握手（HTTPS）、服務器處理、内容传輸。任何一段拖長，這次抓取都會變得更贵。蜘蛛通常不會死等，超时之後要么放弃，要么降低對该站点的抓取频率。
三個值得盯住的數字
- TTFB：首字节時間，反映服務器處理速度。入口頁如果做成静態文件，這一項通常能稳定在几百毫秒以内。
- 完整下载時間：TTFB 加上内容传輸時間。入口頁里塞了大图和外部脚本，這一項會很难看。
- 响應体大小：几 KB 的纯 HTML 和几百 KB 的臃肿頁面，抓取成本完全不同，後者更容易被排在後面。
入口頁常见的拖慢原因
大多數蜘蛛池入口頁不是被流量压垮的，而是被自己寫的東西拖慢的：
- 每次請求都去查資料库，甚至做多表關联，而頁面本身只有几行字。
- 引用了第三方 CDN 上的 JS、字体或統計脚本，蜘蛛抓頁面时顺带触發一堆外部請求，其中一個卡住，整体就慢。
- 层叠跳轉：入口頁先 302，再 JS 跳，再 meta refresh，每一跳都是一次額外的往返。
- 服務器位置與蜘蛛来源相距太遠，跨境鏈路的抖動會被放大。
- 同 IP 上堆了太多站点，某個站被高频抓取，其他站跟着排队。
把体积降下来比什么都直接
入口頁的任務是“被看到並给出下一步”，不需要承载完整内容。纯静態 HTML、少量内联样式、外鏈尽量少，是成本最低的做法。可以先把入口頁改成一個几乎没有依赖的静態文件，再單獨测一次抓取耗时，和改造前做對比。
怎么驗證有没有變快
- 用命令行工具分別輸出 DNS、连接、TTFB、總耗时几個時間值，多测几次取中位數，別只看一次结果。
- 在訪問日誌里查看蜘蛛請求的响應大小與响應時間字段，按 URL 排序，把最慢的几個入口頁挑出来。
- 把入口頁按服務器、模板、上线批次分组横向對比，能判断是共性問题還是個別頁面問题。
- 每次只改一個變量，观察一到两周，不要同时換服務器又改模板。
速度解决不了的問题
响應快只能让蜘蛛更愿意多来几次，它不负责让頁面被收錄。内容單薄、入口頁之間高度雷同、目标頁没有可索引價值，這些都不是提速能补上的。
一份简單的检查清單
- 入口頁能否直接返回静態 HTML，不依赖資料库和第三方资源？
- TTFB 是否稳定，而不是偶尔很快、偶尔几秒？
- 頁面体积是否控制在几十 KB 以内？
- 從入口到下一步的跳轉是否只有一跳？
- 有没有定期在日誌里核對抓取耗时，而不是只看抓取次數？
把速度当成入口頁的基础设施来看待，比事後去猜“為什么蜘蛛不来了”要省事得多。