不少人把抓取理解成“蜘蛛下载 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 请求只占很小一部分，剩下都在拉静态文件，那么该优化的往往不是内容量，而是资源的组织方式。
资源优化不会直接带来排名，但它决定了蜘蛛把有限的访问次数花在哪里。把文件请求控制住，页面本身才有更多机会被完整、及时地抓到。