蜘蛛抓一個頁面，成本由两部分组成：先把响應体下载下来，再解析 HTML、抽取連結和正文。這两步都要花時間。站点每天能承受的抓取次數大体稳定，所以單個頁面越重，單位時間内能走完的 URL 就越少。
為什么体积會變成抓取問题
很多站点把抓取慢归因于服務器或蜘蛛不勤快，實际上問题常常出在頁面自己身上。一個三兆的列表頁和一個几十 KB 的列表頁，蜘蛛拿到的有效連結可能差好几倍：前者大部分字节花在重复的脚本、样式和冗余结构上，真正指向詳情頁的連結却没几條。
更現實的一点是，解析器不會無限讀下去。主流搜尋引擎在解析 HTML 时都有体量或节点數量的上限，超出之後的内容，包括里面的連結标簽，可能直接不參與連結抽取。這是一條硬邊界，不是讀得慢一点的問题。
三個最常见的体积来源
内联的脚本和样式
把整份 CSS 和打包後的 JS 直接寫進 HTML，首屏确實快一点，但每次抓取都要重新下载一遍。這些字节對蜘蛛抽取連結没有任何帮助，属于纯開销。改成獨立的外鏈文件，至少浏览器和蜘蛛都能缓存。
把資料直接塞進頁面
服務端渲染时，不少框架會把整份接口資料序列化進 HTML，用于前端接管。列表頁里一份几百 KB 的 JSON，蜘蛛同样要下载、要跳過。能走接口的就別全量内联，或者只保留首屏真正需要的那部分。
重复的導航、頁脚與广告位
全站统一的導航和頁脚在每個頁面都出現一次，本身不是問题，但如果里面塞了几十條連結外加多层下拉菜單，乘以頁面數就是可观的体积。導航保持精简，邊缘連結可以收進 HTML 站点地图頁面。
連結位置比連結數量更重要
解析是按顺序進行的。同一批連結，放在 HTML 靠前的位置，被讀到的概率明顯更高；埋在几千行 DOM 之後，或者放在懒加载容器里等脚本插入，風險就大得多。
具体来说：
- 正文和列表里的詳情頁連結，尽量出現在前三分之一的结构中；
- 懒加载只做视觉延迟，連結地址要在初始 HTML 里就存在，不要等滚動後才由脚本生成；
- 分頁、下一頁這類路径連結，別放在頁面最底部；
- 把重要入口同时放進導航或面包屑，作為冗余通路。
传輸层的几個细节
- 開压缩：gzip 或 brotli 通常能把 HTML 压到原来的三分之一以下，注意 CDN 與源站不要重复压缩，也別漏掉 text/html 類型。
- 看压缩後的大小：優化目标是传輸字节，不是源文件的体积。
- 减少重定向：每次 301、302 都要多一次往返，等于把抓取時間拉長。
- 保持响應稳定：体积大再加上响應慢，蜘蛛更容易在解析完成前結束這次請求。
排查顺序
- 用 curl 分別看未压缩和開压缩後的响應体大小，挑体积最大的几個模板頁下手。
- 在浏览器里數一下 DOM 节点數，几萬個节点說明结构该拆了。
- 確認重要連結在初始 HTML 里存在，並且位置靠前。
- 把超長的列表頁拆成多頁，或者只渲染首屏，後續用可爬取的分頁連結承接。
- 改完後隔一段時間看抓取日誌，對比同一批 URL 的抓取成功率和單位時間抓取量。
頁面体积不只是性能問题。它直接决定蜘蛛在一次抓取里能带走多少信息，尤其是連結。把 HTML 减到该有的样子，抓取效率的提升往往比換服務器更直接。
最後提醒一句：体积優化没有统一标准，關键是保證重要的連結和正文落在解析范围内，其余的能省則省。做不到一步到位也没關系，先從流量最大、連結最多的几個模板頁開始。