很多人搭建蜘蛛池入口頁时，只要頁面能打開、連結能跳轉就算完成，很少關注頁面体积。實际上，入口頁承担的是“被發現”和“被繼續爬取”的任務，如果單個頁面過大，抓取端下载和解析的成本就會上升，在同等抓取预算下能訪問的 URL 數量可能减少。
頁面体积為什么會拖慢抓取
搜尋引擎蜘蛛抓取一個頁面，大致要经歷下载 HTML、解析 DOM、提取連結三個阶段。体积過大主要影响前两步：
- 下载耗时：同样的带宽下，几百 KB 的 HTML 比几十 KB 的慢不少，尤其是蜘蛛從境外或跨运营商訪問时。
- 解析成本：DOM 节点越多、内联脚本越复杂，解析時間越長，部分抓取端會對超大頁面做截断處理。
- 抓取预算：單頁耗时增加，單位時間内完成的抓取量下降，連結被“看到”的机會自然變少。
這些影响不是绝對的，取决于抓取端的策略和服務器的實际响應情况，但体积是相對容易自己控制的變量之一。
入口頁的体积參考线
- HTML 源碼：常規入口頁控制在 100KB 以内比較從容，超過 300KB 就值得检查有没有冗余。
- DOM 节点：1500 個以内通常解析較快，几千個节点的頁面在移動端會明顯吃力。
- 外部资源：CSS、JS、字体、图片加起来的請求數，建议控制在 15 個以内。
這些是经驗值而非标准，不同類型的站点差异很大，重点是把它們当作自查的起点。
最容易被忽略的三類冗余
1. 模板自带的整站资源
很多入口頁是從主站或某個模板複製過来的，带着整站導航、轮播图脚本、评论组件。這些内容入口頁根本用不到，却會一並被下载和加载。
2. 全量引入的图标库與字体
為了几個图标引入一個几百 KB 的字体文件，或者加载完整图标集，是很常见的浪費。可以改成内联 SVG 或使用图标字体子集。
3. base64 图片與未压缩图片
把图片轉成 base64 直接寫進 HTML，會让 HTML 本身膨胀，並且無法被單獨缓存。图片该压缩就压缩，该放到獨立资源地址就獨立放。
精简时不要丢掉的東西
- 指向目标頁的連結和锚文本，這是入口頁存在的意义。
- 一定量的正文文本，纯連結堆砌的頁面可讀性差。
- 能正常訪問的狀態碼與相對稳定的响應。
一個可执行的精简顺序
- 先用浏览器開發者工具或命令行工具看 HTML 大小和請求數量，找出体积最大的几個文件。
- 删掉入口頁用不到的整站脚本和样式，只保留頁面實际渲染需要的部分。
- 压缩 HTML、CSS、JS，開啟 gzip 或 brotli。
- 图片換格式、降尺寸，非首屏图片延迟加载。
- 改完後连續观察几天的抓取日誌，對比抓取數量和到達目标頁的比例。
体积精简的目标是让頁面更“轻”，而不是做极限压缩。為了省下几百字节把维護性搞得很差，反而得不偿失。
常见誤区
- 越轻越好：把内容砍到只剩一行連結，頁面质量下降，可能得不偿失。
- 只看一個样本：入口頁往往是模板批量生成的，要抽查多個頁面而不是只看一個。
- 用前端渲染省流量：把正文改成异步加载並不會减少抓取端的工作量，反而增加不确定性。
- 压缩後不驗證：压缩配置寫错導致脚本报错、頁面白屏，比体积大更麻烦。
最後，体积只是入口頁可维護性的一部分。把体积、响應速度、狀態碼、連結结构放在一起看，定期做小批量抽查，比一次性大改更稳妥。