蜘蛛拿走一个页面，要花三笔成本
把抓取想成一次有限的搬运。搜索引擎每天给站点分配的请求量大致有数，每一次抓取都要付出代价。页面越重，同样的抓取次数能覆盖的 URL 就越少，这是体积问题真正值得关注的地方。
- 传输成本：服务器要吐出多少字节，压缩前和压缩后差多少。
- 解析成本：HTML 有多少节点、嵌套多少层，解析和后续处理要多久。
- 渲染成本：如果内容靠 JS 生成，还要排队执行脚本、发出子请求。
这三笔里，前两笔你能直接控制，第三笔通常最贵。
HTML 源码：先确认正文有没有出现在里面
有些页面源码体积并不大，但正文是空的，全部内容等 JS 填充。蜘蛛第一次抓到的只是一个壳，要进入渲染队列再回来一趟，成本翻倍。这类页面在列表页、聚合页上尤其常见。
另一类相反：源码里塞了大量与正文无关的东西——内联的样式和脚本、base64 编码的小图标、把整张参数表序列化成 JSON 放在页面里。用户看不到更多信息，但每个 URL 的下载量翻了几倍。
DOM 深度与节点数量
DOM 的深度和节点总数，影响的是解析与渲染阶段的耗时。常见现象是模板层层嵌套，一个列表项外面套了七八层 div，节点数轻松过万。节点越多，渲染越慢，蜘蛛在这个页面上停留的时间越长。
实操中，把无意义的包裹层去掉、用更扁平的标签结构，效果往往比压缩几 KB 图片更明显。
资源请求的连带代价
蜘蛛抓取 HTML 之外是否还会取图片、CSS、JS，各家引擎策略并不完全一样。能做的有几件：确保首屏关键内容不依赖某个必须下载成功才能显示的脚本；图片放到 CDN 或独立域名，减少主域名的并发压力；把不影响理解的装饰性资源往后放。
可以动手的几件事
- 查看页面源码，搜索正文里的第一段话，看它在不在 HTML 里。不在，说明内容依赖 JS。
- 对比 HTML 原始大小与 gzip、Brotli 之后的大小，差距过小通常说明压缩没配好或内容太杂。
- 把内联的长脚本、长样式提到外部文件并设置缓存，减少每个页面的重复传输。
- 检查列表项、卡片这类重复结构的 DOM 层数，能减一层是一层。
- 用开发者工具看一次完整加载发出多少请求，数量偏多就该考虑合并或延后。
体积优化不是为了让蜘蛛“喜欢”你，而是让同样的抓取额度覆盖更多 URL，让服务器在抓取高峰时还有余力响应真实用户。
别只盯首页
首页通常是最轻的那一页。真正的问题在列表页和详情页模板——它们数量最多、被抓最频繁。挑一个典型详情页量一下，比反复测首页有意义得多。
如果站点是批量生成的，一个模板偏胖，就是成百上千个 URL 一起偏胖。先修模板，再看整体抓取量的变化。