聊抓取的时候，大家习惯盯抓取条数：今天来了多少次、覆盖了多少 URL。但很少人看每次抓取实际传了多少字节。对蜘蛛来说，时间是一份相对固定的预算，服务器响应、数据传输、HTML 解析都要从这份预算里扣。页面越重，同样一段时间里能走完的 URL 就越少。
一次抓取的耗时由几段组成
把一次抓取拆开看，大致是：建立连接、等待服务器返回首字节、下载响应体、解析 HTML 并提取链接。前三段和服务器、网络有关，最后一段和页面结构有关。很多站点只优化了首字节，却忽略了响应体本身。
举个粗略的对比：同样是一千个页面，如果每个页面的 HTML 从 200KB 压到 40KB，蜘蛛在传输环节省下的时间相当可观。这不保证抓取量一定上升，但至少不会因为页面太胖而把时间耗在下载上。
体积通常从哪里来
内联的脚本与样式
为了减少请求，不少站点把 CSS 和 JS 直接内联进 HTML。少量内联是合理的，但如果整站把框架代码、图标字体、统计脚本全塞进每个页面，HTML 会迅速膨胀。更极端的是把图片转成 base64 内联，一张图就能顶掉几十 KB。
重复的模板区块
导航、页脚、侧边栏、推荐位，这些内容每个页面都有。它们本身不算冗余，但如果再加上多层嵌套的容器、大量的 class 名和属性，模板部分的体积会明显超过正文。
列表页的卡片内容
列表页往往塞进摘要、标签、作者、时间、阅读量、封面缩略图。这些对用户有用，但对蜘蛛来说，真正需要的是指向详情页的链接。列表页体积失控，最先受影响的就是分页和翻页链接的发现效率。
压缩与传输
HTML 是文本，压缩收益很高。开启 gzip 或 brotli 后，传输体积通常能降到原来的两三成。检查一下服务器是不是对所有 text/html 响应都开了压缩，有些配置只压了 JS 和 CSS，HTML 反而漏掉了。
另外注意响应头里的 Content-Length 和实际传输量是否一致，以及有没有在 HTML 里重复输出大段 JSON 数据。前端渲染需要的初始数据，能精简就精简。
DOM 深度与出链位置
体积不只是字节数，还包括结构层级。DOM 嵌套过深时，解析成本上升，链接也容易被埋在中后段。一个实用的原则是：让重要的内链尽量出现在较浅的层级，不要为了样式包裹五六层 div 才放一个 a 标签。
同样地，如果链接是通过脚本在页面加载后动态插入的，蜘蛛即便拿到了 HTML，也未必能立刻看到这些出链。能用服务端直出的导航和列表，尽量直出。
抓取路径上的连锁反应
页面重，影响的不只是单个 URL。列表页变慢，蜘蛛从这里发现新 URL 的速度就下降；详情页模板臃肿，每个被抓的页面都多花一点时间。这些损耗叠加起来，表现在日志里就是抓取频次没变、但覆盖的独立 URL 变少。
体积优化不是一次性动作。模板改一次，所有页面都会跟着变，值得放在和内容更新同等的位置去对待。
可以这样自查
- 抓几个典型页面的原始 HTML，看未压缩大小，区分正文、模板、内联资源的占比。
- 确认服务器对 HTML 开启了压缩，并对比压缩前后的传输字节。
- 检查列表页和详情页的 DOM 层级，找出嵌套最深的区块。
- 看服务器日志里的响应时间和响应体大小，找出又大又慢的那批 URL。
- 把改动前后的抓取日志做对比，观察独立 URL 数量是否变化。
写在最后
抓取优化里，体积是最不玄学的一环：改了什么，日志里基本能看到。它不会直接带来排名，但会让蜘蛛在同样的时间里多走几页。对小站来说，这可能就是多抓几十个 URL；对大站来说，是整体抓取效率的底数。