抓取端下载的是响應体，不是完整的網頁体驗

很多人做入口頁时习惯按做普通網站的思路来——加轮播图、加統計脚本、加字体文件、加一堆图标库。這些對真實用戶有意义，但對抓取端来说，它拿到的通常只是服務器返回的那一段 HTML。理解這一点，頁面体积的帳才容易算清楚。

抓取端做的基本動作是：發起請求、拿到响應头、讀取响應体、從中抽取連結和文本。响應体越小、结构越清晰，這個流程走完越快，也越不容易在解析阶段出错。

HTML 体积控制在什么范围比較稳妥

没有统一的官方标准，但從實践看，入口頁的 HTML 建议控制在 100KB 以内，几十 KB 更理想。超過几百 KB 會遇到几個問题：

• 传輸時間變長，尤其在網絡抖動时，抓取端可能中途放弃或超时。
• 解析成本上升，正文和連結被淹没在大量标簽里。
• 部分抓取端對單頁有体积上限，超出部分可能被截断，連結正好落在尾部就丢了。

常见的把 HTML 撑大的原因：内联了整份 CSS、把图片轉成 base64 寫進 HTML、模板里塞了大量隐藏文本、複製粘贴带来的冗余嵌套标簽。這些都可以在模板层统一清理。

外鏈的 CSS、JS、图片會被請求吗

這取决于抓取端的類型，不能一概而论。

• 不渲染的抓取端通常只取 HTML，遇到 link rel=stylesheet、script src、img src 一般不會去下载，除非它需要做渲染。
• 带渲染能力的抓取端會尝试加载渲染所需资源，這时外鏈资源越多、越大，完成渲染的時間就越長，也可能因為某個资源超时而放弃。

所以稳妥的做法是：入口頁的正文和連結尽量直接出現在 HTML 里，不要依赖 JavaScript 動態生成。這样無论哪種抓取端来，看到的内核是一致的。至于样式和脚本，能外鏈就外鏈，能精简就精简，不必為了「看起来完整」把整站资源都搬到入口頁上。

判断标准很简單：把頁面的 JS 全部關掉，如果正文和連結還在，說明结构是稳的；如果關掉就一片空白，那抓取端也可能看到一片空白。

压缩和传輸层能省不少

服務器開啟 gzip 或 brotli 後，HTML 在传輸时會被压缩，几倍的体积差很常见。這一步對抓取端友好，對服務器带宽也友好，属于低成本改動。注意响應头里的 Content-Encoding 要正确，压缩配置出错會導致抓取端拿到乱碼甚至报错。

另外，入口頁如果是静態结构，直接輸出静態文件往往比走模板渲染更快也更稳定。

自己動手查一遍

不用复杂工具，命令行就够：

• 看响應头：curl -sI 你的入口頁地址，關注 content-length、content-encoding、content-type。
• 看体积：curl -s 你的入口頁地址 | wc -c，得到未压缩的字节數。
• 看结构：把返回的 HTML 存下来，搜尋正文關鍵詞和出口連結，確認它們都在源碼里。

如果 wc -c 的结果遠超预期，先找体积来源，通常是内联样式或者大段模板注释。

几個容易踩的坑

• 為了「顯得正常」堆一堆第三方脚本，结果入口頁拖到几百 KB，抓取端反而更容易超时。
• 把出口連結藏在 JS 渲染出来的列表里，不渲染的抓取端一條也拿不到。
• 用 base64 内联图片，HTML 直接膨胀好几倍，收益却只在视觉上。
• 压缩開啟後没有驗證，抓取端收到的是损坏内容。

小结

入口頁的核心任務是让抓取端快速、准确地看到連結和内容，頁面体积和资源加载都是围绕這個目标服務的。把 HTML 控制在合理范围内，把關键内容放在源碼里，压缩配置核對一遍，通常就能避開大部分與体积相關的抓取問题。