抓取端下载的是响应体，不是完整的网页体验

很多人做入口页时习惯按做普通网站的思路来——加轮播图、加统计脚本、加字体文件、加一堆图标库。这些对真实用户有意义，但对抓取端来说，它拿到的通常只是服务器返回的那一段 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 控制在合理范围内，把关键内容放在源码里，压缩配置核对一遍，通常就能避开大部分与体积相关的抓取问题。