蜘蛛读一个页面，本质是一次下载任务
很多人把抓取理解成“打开页面看看内容”，实际上对蜘蛛来说，抓取一个 URL 就是发一次请求、等响应头、下载响应体，再决定要不要解析。这个过程中，任何一个环节拖得太久或内容太大，都可能导致蜘蛛提前收手：它可能只读到一部分内容，也可能这一轮直接跳过，等下次再试。搜索引擎并没有公开具体的体积上限和超时阈值，但把这些环节控制在一个合理范围内，对抓取效率总是有帮助的。
影响单页抓取的三个变量
首字节时间（TTFB）
从请求发出到收到第一个字节的时间，决定了蜘蛛要等多久才能确认页面还活着。TTFB 主要由服务端处理时间决定：数据库查询、模板渲染、缓存未命中、反向代理回源，都会把它推高。当一个站点整体 TTFB 偏高时，蜘蛛在同样的时间窗口里能完成的请求数就会下降，表现为抓取频率变低、回访间隔变长。
传输体积
响应体大小直接决定下载需要的时间。一个正常的内容页，开启 gzip 或 brotli 压缩后，HTML 通常在几十 KB 量级；如果未压缩，又塞了大量内联脚本和样式，很容易膨胀好几倍。需要提醒的是，蜘蛛下载的是压缩后的字节，但解压和解析的仍然是解压后的内容，所以“压缩了但内容本身很臃肿”，只是把问题从传输环节挪到了解析环节。
解析成本
DOM 节点数量、嵌套层级、内联脚本执行时间，都会影响蜘蛛在拿到 HTML 之后的理解过程。一个几万节点的页面，即使体积不大，处理起来也比结构清晰的页面更费劲。
哪些“大文件”会占住蜘蛛的时间
- 首页或列表页内联了完整的前端框架和全量数据，动辄几百 KB 到上 MB；
- 以 HTML 形式返回的大 JSON，接口未做分页或直接吐出全量数据；
- 被当作页面提交的 PDF、压缩包、音视频等二进制文件；
- 参数分页没有边界，蜘蛛顺势爬进成千上万条组合 URL。
关键不是“文件大就一定不抓”，而是这类 URL 往往抓取价值低、占用资源高。把它们清理出内链，或者用 noindex 明确态度，通常比留给蜘蛛慢慢试更划算。
服务器与传输层面的几个习惯
- 开启压缩：对 HTML、CSS、JS、JSON 启用 gzip 或 brotli，并确认压缩确实生效，可以看响应头里的 Content-Encoding。
- 合理设置缓存：静态资源用长缓存，HTML 用短缓存或不缓存，避免蜘蛛每次都触发完整回源。
- 避免流式输出过慢：边算边吐的接口如果中途卡住，蜘蛛可能只拿到半截内容。
- 支持分块传输与长连接：减少连接建立开销，让同一批请求更快走完。
- 不要用大体积 HTML 承载分页数据：列表页只放当前页内容，其余交给分页 URL。
怎么判断自己有没有踩到线
- 用 curl 或浏览器开发者工具查看单个页面的 TTFB、传输大小和总耗时，取样几个典型页面，而不是只看首页。
- 在服务器日志里按响应体大小排序，找出明显偏大的 HTML 响应。
- 对比开启压缩前后的字节数，确认压缩没有因为 MIME 类型配置错误而失效。
- 抽查蜘蛛访问日志中的状态码与耗时，看是否有一批 URL 长期处于慢响应状态。
体积和耗时不是越小越好的绝对指标，而是关系到蜘蛛在一个抓取周期内能覆盖多少 URL。页面内容多一些没问题，前提是别让传输和解析成本失控。
把单个页面的下载成本控制住，蜘蛛才有余力去走更多路径。与其纠结某一次抓取有没有发生，不如先检查一遍：响应快不快、体积大不大、结构清不清晰。这三件事理顺了，抓取效率自然会稳定一些。