抓取不是一瞬間完成的動作
很多人看日誌时只關心“蜘蛛来過没有”，但日誌里的每一條抓取记錄，背後都有一段有先後顺序的過程：DNS 解析、建立连接、發送請求、等待服務器首字节、接收响應体、解析 HTML、把新發現的連結放進队列。前面几步决定“能不能抓”，後面几步决定“抓到了什么”。頁面体积影响的主要是後半段。
体积通常大在哪几個地方
- HTML 本身的長度：列表頁一次性輸出几百條记錄，每條都带完整描述，頁面源碼很容易變得很重。
- 内联的大块内容：把图片轉成 base64 寫進 HTML，或者把整段样式、大段配置資料直接塞進模板。
- 頁面里的資料表：埋点配置、字典表、地理資料這類内容如果寫在模板里，蜘蛛每次抓取都要完整下载一遍。
這些内容對用戶未必可见，但對蜘蛛来说是實實在在要下载的字节。
分块传輸與“先把头部吐出来”
HTTP/1.1 的 chunked 传輸和流式輸出，可以让服務器先把 HTML 的開头部分發出去，而不必等整個頁面拼装完成再一次性發送。對蜘蛛来说，這意味着更早拿到 head 和前半部分的連結，减少因為整体等待超时而抓取失敗的概率。
需要注意的是，分块传輸改變的是資料到達的节奏，總量並没有减少。頁面本身有多大，传完還是多大，只是過程更平滑。它缓解的是“迟迟不開始”，不是“内容太多”。
压缩、缓存與重复抓取
開啟 gzip 或 brotli 压缩，能明顯减少 HTML、CSS、JS 的传輸字节，對蜘蛛和真實用戶都有好處。同时，配置好 Cache-Control、ETag、Last-Modified，让蜘蛛重复抓取时能拿到 304，也是在给這條鏈路减负。反過来，如果缺少缓存相關信息，蜘蛛每隔一段時間就要完整下载一遍体积很大的頁面，長期看會占用本可以用于發現新 URL 的抓取量。
超时：處理慢和传輸慢是两回事
服務器處理慢，通常表現為首字节時間長；传輸慢，則表現為响應体下载時間長。两者都會让蜘蛛等待，但排查方向不同：前者要看資料库、缓存和後端逻辑；後者要看带宽、CDN 回源，以及响應是否被中間层整体缓冲。如果日誌里有响應字节數和耗时字段，可以大致区分這两種情况。
几個可落地的調整
- 列表頁做真實分頁，單頁條目控制在一個合理數量，不要靠“加载更多”把几十頁内容压進同一個 URL。
- 把内联的大段資料外鏈成静態资源，並让這些资源可以被長期缓存。
- 開啟压缩，同时检查中間层是否把流式响應改成了整体缓冲。
- 图片使用正常外鏈方式，不要預設 base64 内联，除非這張图确實是首屏關键元素。
- 在日誌里按响應字节數排序，找出体积最大且被抓取最频繁的那批 URL。
調整之後看什么
体积優化完成後，可以观察同一路径的抓取次數、响應字节數、平均耗时，以及新 URL 被發現的速度是否有所變化。不過這些指标同时受站点结构、更新频率和服務器状况影响，單一變量的效果往往需要一段時間的對比才能看出趋势，不适合用几天的資料就下结论。
頁面体积不會直接决定收錄，但它决定了每個抓取名額能換回多少有效信息。在抓取量有限的情况下，让蜘蛛更快地拿到同样的連結，通常比堆更多内容更划算。