頁面体积和抓取的關系
蜘蛛抓一個頁面，不是只看“能不能打開”，還會看“打開要多久、要拉多少字节”。入口頁越大，單次抓取消耗的時間和带宽越多：在同样的抓取額度下，能跑的頁面就變少；在服務器响應慢的时候，還更容易触發超时，最後只抓到半截 HTML。
所以体积不是“越小越好”的美学問题，而是抓取成本和抓取成功率的權衡。入口頁本身没什么正文，主要作用是让蜘蛛顺着連結往下走，那它更没有理由做得很重。
几個可以參考的數量級
不同搜尋引擎的阈值不一样，也没有公開的硬性标准，下面只是经驗上的參考区間，不是保證：
- 纯 HTML 文档（压缩前的源碼）控制在 100KB 以内比較稳妥，超過 200KB 就值得回头看看是不是塞了不该塞的東西。
- 首字节時間（TTFB）尽量控制在几百毫秒内，超過 1～2 秒，蜘蛛的耐心和你自己的用戶都會下降。
- 一個頁面上的可点击連結，几百個以内比較常见；入口頁如果做成上千條連結的“目錄墙”，蜘蛛通常也走不完。
這些數字不要当红线背，重点是出現異常时知道往哪個方向查。
入口頁被撑大的常见原因
- 内联 CSS 和 JS：模板為了省一個請求，把大段样式和脚本直接寫在 HTML 里，结果每個入口頁都重复一份。
- base64 图片：小图标内联還行，大图内联會让 HTML 膨胀好几倍。
- DOM 层級太深：几十层嵌套的 div，加上大量隐藏节点，解析成本跟着上升。
- 把正文或列表直接堆在入口頁：有些做法為了“看起来有内容”，把大量文本、商品、文章摘要铺满首頁，頁面自然變大。
- 第三方統計、广告、字体脚本：它們不一定阻塞蜘蛛，但會拖慢渲染並占用带宽。
怎么判断是不是体积出了問题
看抓取日誌里的响應字节數、响應時間和狀態碼，是最直接的。如果同一批入口頁里，只有体积大的那部分频繁超时、被抓次數明顯偏少，方向就比較清楚了。也可以用外部工具拉一次頁面，看压缩传輸後的大小、TTFB 和請求數。
別只看“浏览器打開挺快的”，本机缓存和網絡條件會掩盖很多問题。
可以做的几件事
- 把 CSS、JS 抽成外部文件，開啟 gzip 或 brotli 压缩。
- 入口頁只保留導航和必要的摘要，正文内容放到目标頁。
- 控制單頁連結數量，需要铺開就分頁、分层，而不是一張頁面全塞。
- 图片走 CDN 並压缩，放弃大图内联。
- 精简模板，去掉没用的注释、空白和废弃组件。
- 改完之後观察一段時間，對比抓取频次和超时比例，而不是改完就認定有效。
两個容易走偏的地方
一是把体积当成唯一指标，為了“轻”把入口頁做成只有一行連結的空白頁，蜘蛛没有可判断的内容，同样不理想。二是以為压缩率越高越好，压缩只是传輸层的事，解析後的 DOM 依然會被處理，结构臃肿的問题還是要在模板层面解决。
入口頁的体积管理，说到底是在给蜘蛛省時間，也是在给自己省服務器资源。每次調整只動一两個變量，观察日誌再决定下一步，比一次性大改要稳。