不少人把抓取理解成“蜘蛛下载 HTML”，事實比這宽一些：蜘蛛拿到頁面後，通常還會顺着解析结果去請求頁面引用的资源——图片、JavaScript、CSS、字体，有时還包括頁面加载时就發出的接口。這些請求同样占用连接數、带宽和服務器的响應能力。一個頁面挂着上百個静態文件时，蜘蛛跑完這一頁的成本，可能比抓十個纯文本頁還高。
资源請求為什么會算進抓取通道
對搜尋引擎来说，要判断一個頁面“長什么样”，就必须把渲染所需的文件拿到手。JS 决定内容是否出現，CSS 决定元素是否可见，图片决定頁面是否完整。于是這些文件被放進同一套抓取調度里排队，和 HTML 共享同一份服務器资源。资源重的站点，常见的問题不是“頁面抓不完”，而是“時間花在了文件上”。
渲染型资源：JS 與 CSS
這两類文件不下载，蜘蛛看到的可能就是一個空壳，所以它們通常優先級不低。麻烦在于：一份体积很大的 JS 會把渲染往後推，蜘蛛等待變長，單次抓取能覆盖的 URL 就變少。比較典型的情况是首屏依赖几個大包，而蜘蛛訪問时恰好没有命中缓存，服務器還要現算一遍。
數量型资源：图片、图标、字体
單張图片不大，數量一多就成了负担。列表頁尤其明顯：一個頁面几十張缩略图，加上图标字体、雪碧图碎片、多個字体子集，請求數很容易上百。蜘蛛不會因為“這些不是正文”就跳過，只要頁面上寫着要加载，它就可能去取。
第三方脚本與接口調用
統計、客服、埋点、推荐位這類外部脚本，往往在頁面加载早期就開始請求。它們未必都會被蜘蛛执行，但只要被引用，就可能進入請求列表。接口轮询、首屏就發起的列表請求也是同理。這些請求不产生正文，却會實實在在占用响應時間和连接。
资源抓取拖慢了什么
- 抓取覆盖：同样的調度能力被静態文件分走一部分，新頁面和深层頁面就排到後面。
- 服務器压力：HTML 請求通常短而少，静態文件請求數量大、並發高，小带宽服務器更容易抖動。
- 渲染结果：资源取不全，蜘蛛看到的頁面就残缺，内容判断容易偏。
可以從哪几個方向收敛
- 合並與压缩。把散落的小 JS、小 CSS 合並，開啟 gzip 或 br，图片按實际展示尺寸輸出，而不是上传原图再靠 CSS 缩小。
- 让静態文件走 CDN。图片、脚本、字体交给 CDN，源站只處理 HTML 和接口，蜘蛛的請求就不會全部压在源站上。
- 谨慎用 robots.txt 屏蔽资源。屏蔽图片目錄有时能省請求，但如果挡掉了渲染必需的 CSS 和 JS，蜘蛛很可能只看到空白頁面，得不偿失。
- 處理懒加载的邊界。要保證首屏和關键内容在無交互时也能加载，否則蜘蛛拿到的是占位图。
- 用图片 Sitemap 补充信息。它不能替代頁面抓取，但能帮助蜘蛛理解哪些图片與頁面相關。
- 在日誌里驗證效果。按文件類型統計蜘蛛請求的占比，看图片和 JS 是不是吃掉了大头，再决定優化顺序。
判断标准很简單：如果一次抓取里 HTML 請求只占很小一部分，剩下都在拉静態文件，那么该優化的往往不是内容量，而是资源的组织方式。
资源優化不會直接带来排名，但它决定了蜘蛛把有限的訪問次數花在哪里。把文件請求控制住，頁面本身才有更多机會被完整、及时地抓到。