很多站点只关注“蜘蛛来没来”，却很少关注“蜘蛛来了之后，单位时间内能带走多少页”。这两件事其实相关：如果单个页面的 HTML 很重，同样的抓取窗口里，蜘蛛能走完的 URL 数量就会变少。
抓取吞吐，是被什么卡住的
蜘蛛同时能抓多少页，受两边约束：一边是站点自身的容量与响应速度，一边是它给站点分配的抓取配额。在配额相对固定的前提下，每个页面消耗的成本包括：连接与等待时间、响应字节数、解析所需的计算量。字节数是最容易被忽略的一项。
一个普通内容页，HTML 压缩后几十 KB 是常态。但如果内联了大量样式、脚本、base64 图片或整段 JSON 数据，单页很容易膨胀到几百 KB 甚至上 MB。抓取带宽和解析能力都是有限的，这类页面会把资源从“能多抓几页”挤成“只能抓这一页”。
哪些写法会让 HTML 悄悄变重
- 内联大段 CSS 或 JS：为了减少请求，把整包样式或组件库塞进 HTML，页面越多，重复成本越高。
- base64 图片与字体：把图片编码进 HTML 或 CSS，体积通常比原文件大三成以上，而且无法单独缓存。
- 页面里直接灌数据：把接口返回的完整 JSON 写进 script 标签，列表页、商品页尤其常见。
- DOM 节点过多：层层嵌套的容器、大量隐藏节点，会明显拉长解析时间。
- 注释与冗余属性：老模板残留的注释、重复的 data 属性，累积起来也不小。
瘦身不是删内容，而是换位置
先分清两类东西：蜘蛛必须拿到的（正文、链接、结构化数据）和可以延后的（样式细节、非首屏组件、统计脚本）。优化方向是让前者尽早出现、尽量轻，让后者挪出 HTML 本身。
目标不是把页面做得“看起来简单”，而是让关键内容在更少的字节里被完整读到。
可以立刻做的几件事
- 开启 gzip 或 brotli 压缩，HTML、CSS、JS、JSON 都能受益；注意不要对已经压缩过的图片重复压缩。
- 把内联样式与脚本外链化，HTML 里只保留首屏必需的关键 CSS。
- 图片用真实文件引用，不上 base64；列表页缩略图控制尺寸。
- 接口数据不要整包塞进页面，改为按需请求，或只输出渲染必需的字段。
- 清理模板里长期不用的注释、埋点和隐藏节点。
抓取窗口里，还有几个相关变量
- 响应时间：TTFB 越长，每次抓取的等待越多，吞吐自然下降。
- 状态码与错误率：大量 5xx 或超时会让蜘蛛降低抓取频率，等于变相减产。
- 重复 URL：同一内容存在多个地址，等于把配额花在重复页面上。
- 链接位置：把导航、面包屑、正文链接放在 HTML 前部，解析早期就能拿到下一跳。
怎么判断自己是不是“重页面”
不一定需要复杂工具：抓几类代表性页面的原始 HTML（未渲染、压缩后），看体积分布；再对照服务器日志里蜘蛛的抓取次数与响应时间，看是否某一类模板明显拖慢。如果某类模板的字节数远高于其他页面，同时被抓频率偏低，通常值得优先处理。
最后提醒一句：页面体积只是抓取效率的一个变量，不是排名因素。把它当作“让蜘蛛多跑几页”的工程手段，比当作优化技巧更靠谱。