体积为什么会影响蜘蛛的抓取
蜘蛛抓一个页面，成本不只是“发一次请求”。它要占用连接、下载字节、解析 HTML、抽取链接，再把新 URL 放进待抓队列。同样一份抓取预算，花在解析一个 1.5MB 的页面上，和花在解析十个 80KB 的页面上，最终能发现的 URL 数量差距很明显。所以入口页的体积，本质上是抓取效率问题，不是美观问题。
还需要注意，蜘蛛对页面大小通常有截断机制：超过一定字节数后，后半部分可能不再解析。如果待发现的链接恰好堆在 HTML 后半段，那它们大概率不会被看到。
什么把入口页撑大了
- 把整站 CSS、JS 内联进每个入口页，几千个页面各自重复一遍。
- 用 base64 把图片、字体直接塞进 HTML。
- 模板里带大量装饰性 DOM，链接只占其中很小一部分。
- 每个 a 标签挂一串 data-* 属性、onclick 和内联样式。
- 整页输出一份 JSON 数据或全站导航树，在每个页面重复出现。
这些东西对“让蜘蛛找到链接”几乎没有帮助，却真实消耗了抓取额度。
一个粗糙的参考量级
没有硬性标准，但可以按这个方向压：纯链接列表型入口页，HTML 控制在 50KB 以内比较舒服；带一点内容包装的入口页，100KB 上下也能接受；超过 300KB 就该回头看看是不是塞了不必要的东西。压缩传输（gzip / brotli）能显著降低下载字节，但它不减少蜘蛛在解析前需要做的解压与 DOM 处理，所以别把压缩当成万能药。
体积优化的目标是让链接占比变高，而不是让数字好看。
它和响应时间不是一回事
TTFB 高，蜘蛛可能在超时前就放弃；体积大，蜘蛛能拿到页面但解析更慢、能带走的链接更少。两个问题常同时出现，排查方向却不同：前者看服务器、数据库、缓存；后者看模板、内联资源、DOM 数量。翻访问日志时，响应字节数（body_bytes_sent）往往比“请求数”更值得关注。
实际能做的几件事
- 外置 CSS 和 JS，用带指纹的静态文件路径，让浏览器和蜘蛛各取所需。
- 图片走独立 URL，不要 base64 内联。
- 精简模板，删掉不影响链接抽取的包装层。
- 待发现链接多时，做分页或分目录，别在一页里硬塞几千条。
- 如果确实要放结构化数据，考虑用独立接口输出，而不是嵌进 HTML。
几个常见误区
- 体积小就一定抓得多。不一定，链接是否可解析、是否可访问、是否值得跟，同样重要。
- 开了压缩就不用管体积。压缩省的是带宽，HTML 本身的复杂度还在。
- 体积大只是慢一点。它可能直接导致后半页的链接不被解析。
- 移动端和桌面端体积差不多就行。移动蜘蛛的容忍度通常更低，移动模板更该瘦身。
怎么自查
用 curl 拉一次入口页，看 Content-Length 和压缩后的实际字节；把 HTML 存下来，看 a 标签数量占总行数的比例；再到访问日志里对比几个入口页的响应字节数和被跟随的链接数。多数情况下，把体积压下来之后，同样的抓取次数能带出更多 URL，这就是最直接的收益。