聊抓取效率时，很多人先看 URL 數量、抓取频次、Sitemap 提交量，却忽略了一個更基础的變量：每個 URL 返回的响應体有多大。蜘蛛一次抓取，不只要建立连接、等待响應，還要把 HTML 讀進来、解析出連結和正文。頁面越重，單次抓取占用的時間和带宽越多，留给其他 URL 的机會自然會被压缩。
一次抓取，蜘蛛實际要處理什么
從蜘蛛的视角看，一次抓取大致包括：請求 URL、等待首字节、接收响應体、解析 HTML、提取可跟進連結。抓取预算经常被理解為“能發多少個請求”，但在實际調度里，响應時間、响應体大小、解析失敗率都會影响下一次請求什么时候發出。一個 2MB 的 HTML 和一個 20KB 的 HTML，即使 URL 數量相同，對抓取通道的占用也完全不同。
頁面變“重”的常见原因
- 把大量结构化資料直接内联在 HTML 里，例如首屏就塞進几千條商品或文章记錄。
- 列表頁一次性輸出過多條目，分頁形同虚设。
- 把 CSS、JavaScript 甚至 Base64 图片全部内联，導致 HTML 体积成倍增長。
- 服務端把评论、歷史版本、隐藏 Tab 的内容全部渲染進同一個頁面。
- 没有開啟压缩，或者压缩只對静態资源生效，HTML 仍是原始大小传輸。
体积過大时，抓取侧可能出現哪些變化
需要說明的是，蜘蛛不會因為頁面大就“一定不抓”或“一定不收錄”，但体积過大會带来一些現實影响。首先是接收和解析耗时增加，遇到超时設定較紧的抓取队列，可能只讀到部分响應就結束。其次是解析成本上升，DOM 节点過多时，提取連結和正文的效率下降。再次是同一時間段内能完成的請求數减少，抓取节奏變慢。對于新站或抓取频率本来就不高的站点，這種變化會更明顯。
体积問题很少單獨出現，它往往和服務器响應慢、DOM 复杂、内鏈混乱一起發生。排查时不要只盯 HTML 大小一個數字。
怎么判断自己的頁面是不是太重
- 查看 HTML 原始体积和压缩後体积，分別记錄。压缩後仍然偏大，才更值得處理。
- 观察首字节時間。如果服務器本身响應慢，再小的頁面也會拖累抓取。
- 統計 DOM 节点數量和主要容器的嵌套深度，节点過多會增加解析成本。
- 检查内联脚本、内联样式和 Base64 资源占了多少体积。
- 用抓取日誌對照：蜘蛛是否经常只抓到一半、是否频繁超时、是否很少繼續深入。
做轻量化的几個方向
- 列表分頁：每頁保留合理條數，让蜘蛛通過翻頁逐步發現内容，而不是一次吃下全部。
- 延迟加载但保留連結：图片可以懒加载，但指向詳情頁的 a 标簽尽量在初始 HTML 里可解析。
- 資料异步化：把非首屏、非 SEO 必需的資料放到接口請求里，减少初始 HTML 体积。
- 開啟压缩與缓存：對 HTML 啟用 gzip 或 brotli，配合合理的缓存策略，降低重复抓取的传輸成本。
- 控制内联资源：必要的首屏样式可以内联，但不要把整個 CSS/JS 包塞進每個頁面。
轻量頁面如何配合内鏈和 Sitemap
蜘蛛發現 URL 的路径通常来自 Sitemap、内鏈和外鏈。Sitemap 负责给出候選清單，内鏈负责让蜘蛛在站内繼續走。如果頁面 HTML 很重，解析出的連結可能不完整，内鏈的传導效果就會打折扣。反過来，頁面结构清晰、連結位置靠前、响應体可控，蜘蛛在相同抓取次數里能走到的 URL 會更多。Sitemap 里的 URL 最好也能在站内找到對應入口，避免只靠提交、没有内鏈支撑。
一個更實际的判断顺序
遇到抓取量上不去时，可以先排除服務器稳定性和狀態碼問题，再看頁面体积和解析成本。如果同一批 URL 中，小頁面抓取正常、大頁面明顯偏慢或容易中断，那体积就是需要處理的變量。調整後观察抓取日誌里的响應体接收情况和後續 URL 的抓取數量，不要只看某一天的抓取總量。
把頁面做轻，不等于牺牲内容，而是让蜘蛛用更低的成本拿到该發現的東西。對于依赖持續抓取的站点来说，這往往比單纯增加提交量更值得先做。