抓取從下载開始，体积就是成本
蜘蛛抓一個 URL，第一步是把响應体完整讀下来。頁面越大，下载耗时越長，占用的连接時間越久。對單個頁面来说，几十 KB 和几百 KB 的差別可能只是一次抓取快慢；但放到全站几萬、几十萬個 URL 上，這個差別會直接体現在單位時間内蜘蛛能走過的頁面數量上。
所以頁面体积不只是体驗問题，它同时决定了蜘蛛一趟能覆盖多少地址。
HTML 是怎么變重的
- 把大段结构化資料、样式、脚本内联進 HTML，而不是放在獨立文件里；
- 模板里輸出的隐藏区块、彈窗、多套導航，用戶看不到但蜘蛛要解析；
- 列表頁一次渲染几百條记錄，而用戶通常只滚動到前几十條；
- 注释、調试代碼、重复的 class 名，長期积累下来没人清理。
這些内容多數對蜘蛛理解頁面没有帮助，却要被下载、解析，並占用後續處理环节。
DOM 深度與連結可發現性
蜘蛛要從 HTML 里提取連結。連結埋得越深——包在多层嵌套的容器、需要展開的组件、点了才出現的菜單里——被稳定提取的概率就越低。DOM 层級過深還有一個副作用：正文和導航連結混在一起，蜘蛛更难判断哪些連結值得繼續跟。
比較稳妥的做法是让主導航、分類入口、面包屑在 HTML 里以朴素形式出現，不依赖交互才加载。
懒加载與依赖 JS 的内容
图片懒加载對抓取影响不大，但把連結或正文放在脚本执行後才插入的组件里，就存在風險。渲染能力是有限的，也不是每一次抓取都會等脚本跑完。内容层面的建议很简單：關键連結和主体文本服務端直出，交互增强放在後面。
服務端能做的几個取舍
- 压缩传輸：開啟 gzip 或 brotli，能砍掉相当一部分传輸体积；
- 列表拆分：限制單頁條數，用分頁把長列表切開；
- 缓存與响應時間：把渲染结果缓存起来，减少蜘蛛等待；
- 去冗余：定期清理模板里已经没人用的区块和样式。
用日誌驗證，而不是凭感觉
改動之後，看服務器日誌里蜘蛛的来訪次數、平均响應時間，以及請求被浪費在參數頁或無意义頁面上的比例。体积變小、响應變快，通常表現為同一時間段内蜘蛛走過更多 URL。但這不等于一定會收錄或带来排名，它只是把抓取這條路修得顺一点。
蜘蛛的時間是有限的。让它少花在下载和解析上，才有机會多走几個頁面。