蜘蛛爬到入口页，第一件要做的事是把 HTML 拉回去解析。页面体积越大，这件事越慢；更麻烦的是，某些搜索引擎在超过一定字节数之后会停止处理，后面的内容相当于没被看到。入口页作为蜘蛛进入站点的第一落点，体积控制值得单独拿出来说。
蜘蛛到底会读多少 HTML
Google 的文档里提到过，索引系统对单个 HTML 文件的处理上限大约在 2MB 量级，超出的部分可能不参与索引，脚本和样式等资源还有另外的额度。Bing 也有类似的截断行为。这些数字会随引擎更新变化，不是硬性保证，但方向一致：越靠后的内容，越容易被放弃。
所以体积问题的本质并不是「必须小于某个 KB」，而是「你想让蜘蛛看到的东西，有没有落在它一定会读到的位置」。
体积通常被什么撑大
- 内联的 JS 和 CSS。为了减少请求，把整套样式和脚本塞进 head，一个页面几十上百 KB 很常见。
- base64 内嵌的图片、字体和图标。一张 200KB 的图转成 base64 之后体积还会再涨约三分之一。
- 重复的 DOM 结构。列表、卡片、导航逐条展开，外加多层包裹，正文被一路推到文件尾部。
- 框架生成的冗余属性。data-* 标记、水合所需的大量状态数据，人在页面上看不到，但字节一个不少。
把关键信息往前提
蜘蛛解析 HTML 是顺序进行的，先读到的先被理解。因此入口页的结构顺序，往往比单纯压缩体积更重要：
- head 里先放 title、meta description、canonical、robots 等关键指令，再放样式和脚本。
- body 开头就出现与页面主题相关的可见文字，而不是一张大图加几十行导航。
- 正文里的主要链接尽量安排在前半部分，不要全部埋在页脚的密集链接区。
一个简单的判断方法：把页面源码的前 100KB 单独拿出来看，如果标题、主体文案和主要链接都已经在里面，说明结构是健康的。
懒加载与无限滚动的盲区
不少入口页用懒加载省流量，图片和列表在滚动时才加载。问题在于，蜘蛛不一定滚动页面，也不一定完整执行滚动脚本。结果是人在页面上看得到的内容，蜘蛛拿到的 HTML 里只剩占位符。
比较稳妥的做法是：首屏和主体内容用服务端渲染直接输出，懒加载只留给确实靠后的次要资源；无限滚动则配一个可访问的分页或「查看更多」链接，让内容有一条不依赖脚本的路径。
三个可以立刻做的自查
- 用命令行抓一次页面并统计字节数：curl -s URL | wc -c，看看是否明显超过预期。
- 查看网页源代码（不是开发者工具里渲染后的 DOM），确认主体文案和链接在原始 HTML 中确实存在。
- 翻抓取日志或服务器访问记录，看蜘蛛实际拿到的字节数和耗时，与自己的预期对不对得上。
体积和抓取预算的关系
抓取预算是有限的。蜘蛛在单位时间内能处理的字节数有上限，入口页越臃肿，同样时间能翻的页面就越少，留给其他 URL 的额度也跟着紧张。控制体积不是为了讨好某个数字，而是让每一次来访都尽量有效率。反过来也不必为了极致瘦身把页面拆得七零八落，可读性和维护成本同样要算进去。
几条实践建议
- 把可缓存的 CSS 和 JS 拆成外部文件，靠缓存与压缩解决，不要每页重复内联。
- 图片走常规 URL 交给浏览器缓存，base64 只用于极小的图标。
- 入口页保持结构清晰，正文与主要链接别被脚本、样式挤到文件尾端。
- 站点模板难免有大段公共结构时，至少让正文在 HTML 中出现得足够早。
体积只是入口页健康度的一个维度，它和响应时间、状态码、内容更新一起，影响蜘蛛愿不愿意继续往下走。单独优化一项很难有质变，但任何一项明显拖后腿，都会让其他的努力打折。