抓取不是“到了就算”，還要看讀得完讀不完
很多人看日誌只關心狀態碼和抓取次數，忽略了蜘蛛拿到一個頁面之後還要做一件事：把 HTML 解析一遍，從中提取出可繼續抓取的連結和正文内容。頁面体积、DOM 深度、連結出現的位置，都會影响這一步的效率。当站点有大量结构臃肿的頁面时，蜘蛛在單個頁面上花的時間變多，單位時間内能走完的 URL 就變少。
HTML 体积通常從哪里膨胀
- 模板冗余：每個頁面都带一大段用不到的组件代碼、彈窗和评论区骨架。
- 内联样式和脚本：把本该外鏈的资源塞進 HTML，标簽体积成倍增長。
- base64 图片和字体：直接嵌在 HTML 或 CSS 里，体积遠超外鏈资源。
- 把整份資料以 JSON 形式塞進頁面：列表頁尤其常见，几百條資料全量輸出。
- 大量注释、空白和調试信息没有压缩。
這些内容對用戶未必可见，但都會被下载和解析。可以先用開發者工具或命令行看一下首頁、栏目頁、詳情頁的 HTML 大小，重点確認有没有單個頁面達到几百 KB 甚至超過 1 MB。
内鏈出現的位置，比數量更影响路径
解析时連結有先後顺序。如果導航、栏目入口、相關推荐都被放在頁面後半段，而前面是一大段脚本和样式，蜘蛛要“讀”過前面這些内容才能碰到連結。把主要導航和核心内鏈前置，是成本最低的調整之一。
另一個常见問题是連結由脚本動態插入。如果内鏈依赖异步加载、点击後才渲染，蜘蛛在初始 HTML 里可能根本看不到它。可行的做法是至少给關键入口保留一份静態可讀的連結，動態部分作為补充。
渲染型頁面的取舍
依赖前端渲染的頁面，抓取端要多走一步执行脚本。這一步並非走不通，但會更慢，也更依赖资源能否顺利加载。如果導航、正文和分頁入口能在服務端直出，就不必全部交给前端。對列表頁和詳情頁来说，首屏主要内容直出通常比全量渲染更稳。
传輸层的几個细节
- 開啟 gzip 或 brotli 压缩，纯文本頁面的传輸体积能明顯下降。
- 關注首字节時間，服務端渲染過慢时，等待時間也會被拉長。
- 避免用分块传輸把响應拖得很長，能一次返回的内容不要切成很多小包。
- 静態资源與 HTML 分開處理，不要让頁面 HTML 承担图片的传輸。
可以按這個顺序自查
- 抽查首頁、栏目頁、詳情頁各三個，记錄 HTML 大小和 DOM 节点數。
- 對比压缩前後的传輸体积，確認压缩是否真正生效。
- 查看關键内鏈在源碼中的位置和层級，是否早于大段脚本。
- 關閉脚本後再打開頁面，看核心連結和正文是否仍然可见。
- 结合日誌观察抓取量與頁面体积變化之間的關系，驗證調整是否有效。
体积優化不會直接带来收錄，但它决定了蜘蛛在一個頁面上的讀取成本。当站点規模變大、頁面數量上升时，把單個頁面的讀取成本降下来，往往比反复提交地址更值得做。
把頁面做小、把連結提前、把主要内容直出，這三件事做扎實，蜘蛛的抓取路径通常會更顺。