蜘蛛讀一個頁面，本质是一次下载任務
很多人把抓取理解成“打開頁面看看内容”，實际上對蜘蛛来说，抓取一個 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。頁面内容多一些没問题，前提是別让传輸和解析成本失控。
把單個頁面的下载成本控制住，蜘蛛才有余力去走更多路径。與其纠结某一次抓取有没有發生，不如先检查一遍：响應快不快、体积大不大、结构清不清晰。這三件事理顺了，抓取效率自然會稳定一些。