体积為什么會影响蜘蛛的抓取
蜘蛛抓一個頁面，成本不只是“發一次請求”。它要占用连接、下载字节、解析 HTML、抽取連結，再把新 URL 放進待抓队列。同样一份抓取预算，花在解析一個 1.5MB 的頁面上，和花在解析十個 80KB 的頁面上，最终能發現的 URL 數量差距很明顯。所以入口頁的体积，本质上是抓取效率問题，不是美观問题。
還需要注意，蜘蛛對頁面大小通常有截断机制：超過一定字节數後，後半部分可能不再解析。如果待發現的連結恰好堆在 HTML 後半段，那它們大概率不會被看到。
什么把入口頁撑大了
- 把整站 CSS、JS 内联進每個入口頁，几千個頁面各自重复一遍。
- 用 base64 把图片、字体直接塞進 HTML。
- 模板里带大量装饰性 DOM，連結只占其中很小一部分。
- 每個 a 标簽挂一串 data-* 属性、onclick 和内联样式。
- 整頁輸出一份 JSON 資料或全站導航树，在每個頁面重复出現。
這些東西對“让蜘蛛找到連結”几乎没有帮助，却真實消耗了抓取額度。
一個粗糙的參考量級
没有硬性标准，但可以按這個方向压：纯連結列表型入口頁，HTML 控制在 50KB 以内比較舒服；带一点内容包装的入口頁，100KB 上下也能接受；超過 300KB 就该回头看看是不是塞了不必要的東西。压缩传輸（gzip / brotli）能顯著降低下载字节，但它不减少蜘蛛在解析前需要做的解压與 DOM 處理，所以別把压缩当成萬能药。
体积優化的目标是让連結占比變高，而不是让數字好看。
它和响應時間不是一回事
TTFB 高，蜘蛛可能在超时前就放弃；体积大，蜘蛛能拿到頁面但解析更慢、能带走的連結更少。两個問题常同时出現，排查方向却不同：前者看服務器、資料库、缓存；後者看模板、内联资源、DOM 數量。翻訪問日誌时，响應字节數（body_bytes_sent）往往比“請求數”更值得關注。
實际能做的几件事
- 外置 CSS 和 JS，用带指纹的静態文件路径，让浏览器和蜘蛛各取所需。
- 图片走獨立 URL，不要 base64 内联。
- 精简模板，删掉不影响連結抽取的包装层。
- 待發現連結多时，做分頁或分目錄，別在一頁里硬塞几千條。
- 如果确實要放结构化資料，考虑用獨立接口輸出，而不是嵌進 HTML。
几個常见誤区
- 体积小就一定抓得多。不一定，連結是否可解析、是否可訪問、是否值得跟，同样重要。
- 開了压缩就不用管体积。压缩省的是带宽，HTML 本身的复杂度還在。
- 体积大只是慢一点。它可能直接導致後半頁的連結不被解析。
- 移動端和桌面端体积差不多就行。移動蜘蛛的容忍度通常更低，移動模板更该瘦身。
怎么自查
用 curl 拉一次入口頁，看 Content-Length 和压缩後的實际字节；把 HTML 存下来，看 a 标簽數量占總行數的比例；再到訪問日誌里對比几個入口頁的响應字节數和被跟随的連結數。多數情况下，把体积压下来之後，同样的抓取次數能带出更多 URL，這就是最直接的收益。