抓取不是“到了就算”，还要看读得完读不完
很多人看日志只关心状态码和抓取次数，忽略了蜘蛛拿到一个页面之后还要做一件事：把 HTML 解析一遍，从中提取出可继续抓取的链接和正文内容。页面体积、DOM 深度、链接出现的位置，都会影响这一步的效率。当站点有大量结构臃肿的页面时，蜘蛛在单个页面上花的时间变多，单位时间内能走完的 URL 就变少。
HTML 体积通常从哪里膨胀
- 模板冗余：每个页面都带一大段用不到的组件代码、弹窗和评论区骨架。
- 内联样式和脚本：把本该外链的资源塞进 HTML，标签体积成倍增长。
- base64 图片和字体：直接嵌在 HTML 或 CSS 里，体积远超外链资源。
- 把整份数据以 JSON 形式塞进页面：列表页尤其常见，几百条数据全量输出。
- 大量注释、空白和调试信息没有压缩。
这些内容对用户未必可见，但都会被下载和解析。可以先用开发者工具或命令行看一下首页、栏目页、详情页的 HTML 大小，重点确认有没有单个页面达到几百 KB 甚至超过 1 MB。
内链出现的位置，比数量更影响路径
解析时链接有先后顺序。如果导航、栏目入口、相关推荐都被放在页面后半段，而前面是一大段脚本和样式，蜘蛛要“读”过前面这些内容才能碰到链接。把主要导航和核心内链前置，是成本最低的调整之一。
另一个常见问题是链接由脚本动态插入。如果内链依赖异步加载、点击后才渲染，蜘蛛在初始 HTML 里可能根本看不到它。可行的做法是至少给关键入口保留一份静态可读的链接，动态部分作为补充。
渲染型页面的取舍
依赖前端渲染的页面，抓取端要多走一步执行脚本。这一步并非走不通，但会更慢，也更依赖资源能否顺利加载。如果导航、正文和分页入口能在服务端直出，就不必全部交给前端。对列表页和详情页来说，首屏主要内容直出通常比全量渲染更稳。
传输层的几个细节
- 开启 gzip 或 brotli 压缩，纯文本页面的传输体积能明显下降。
- 关注首字节时间，服务端渲染过慢时，等待时间也会被拉长。
- 避免用分块传输把响应拖得很长，能一次返回的内容不要切成很多小包。
- 静态资源与 HTML 分开处理，不要让页面 HTML 承担图片的传输。
可以按这个顺序自查
- 抽查首页、栏目页、详情页各三个，记录 HTML 大小和 DOM 节点数。
- 对比压缩前后的传输体积，确认压缩是否真正生效。
- 查看关键内链在源码中的位置和层级，是否早于大段脚本。
- 关闭脚本后再打开页面，看核心链接和正文是否仍然可见。
- 结合日志观察抓取量与页面体积变化之间的关系，验证调整是否有效。
体积优化不会直接带来收录，但它决定了蜘蛛在一个页面上的读取成本。当站点规模变大、页面数量上升时，把单个页面的读取成本降下来，往往比反复提交地址更值得做。
把页面做小、把链接提前、把主要内容直出，这三件事做扎实，蜘蛛的抓取路径通常会更顺。