仅译文翻译，最高快 14.9 倍

网页背后看不见的“行李”

一个网页看起来可能只有几段干净的文字，背后却带着成千上万个你看不到的字符：样式 class、追踪数据、链接、图片信息，以及浏览器渲染页面需要的其他说明。

这些信息对网页很重要，但绝大多数不需要翻译。以前在仅译文模式下，陪读蛙会把其中许多隐藏信息和正文一起发给翻译服务。在现代组件密集的网站上，翻译器处理网页结构的时间甚至可能比翻译眼前句子的时间更长。

1.39.5 版本改变了这一点。

发送更少的数据，返回后再完整还原网页

陪读蛙现在会临时收起不需要翻译的属性，只用一个很短的标记记住它们的位置。翻译服务只处理文字和 HTML 结构；译文返回后，陪读蛙会先恢复原有属性，再把结果显示到页面上。

在普通现代文档样本中，请求体缩小了 69.8%；在极端的 Tailwind/GitHub 风格样本中，请求体缩小了 98.2%。

整个过程可以理解成三步：

1. 保留可见文字、HTML 结构，以及可能需要翻译的文字类属性。
2. 把样式、URL、ID 等隐藏属性换成只属于当前请求的小标记。
3. 检查每个标记是否完整，再恢复原始属性并显示译文。

如果某个翻译服务没有正确保留标记，陪读蛙会拒绝这份结果并安全回退，不会把损坏的 HTML 插入网页。

真实 API 测试结果

我们使用构建后的真实扩展，分别测试了 OpenAI、DeepSeek、Google、Microsoft 和 DeepL。提升幅度主要取决于一个翻译片段里藏着多少网页属性。

图中的三列依次代表简单文章、普通现代文档，以及属性非常密集的组件页面。

在 DeepSeek 极端样本中，新请求稳定在大约 1.25 秒。旧请求两次超时，唯一成功的一次耗时 45.5 秒。由于旧方案已经不稳定，我们不会把它宣传成一个稳定的提速倍数。

机器翻译有什么变化？

机器翻译服务本来就很擅长处理 HTML，而且固定网络延迟占比更高，所以速度变化小得多：

即使秒表变化不明显，更小的请求仍能减少不必要的传输，并降低触碰请求长度限制的可能性。

输入 token 更少，LLM 成本也更低

译文内容和输出长度基本不变，因此节省主要来自减少无用输入。在把固定提示词和输出费用也计算进去后，我们估算整次调用的成本下降如下：

• OpenAI： 普通现代页面约省 10–25%，极端属性密集内容约省 80–90%。
• DeepSeek： 普通现代页面约省 20–35%，极端属性密集内容约省 88–94%。

这些数字是根据本次测试请求体和 2026 年 7 月 11 日可查到的价格估算，不代表每个网页都一定达到相同结果。最新价格请查看 OpenAI 和 DeepSeek 官方页面。

陪读蛙内置的 Google 和 Microsoft 翻译不会给用户产生 API 账单。DeepL 的规则又有所不同：开启 HTML 处理后，DeepL 本来就不会对 HTML 标签及其属性中的字符计费，所以这次优化对 DeepL 的价值主要是缩小请求体和提高可靠性，而不是省钱。

你实际会感受到什么

如果你主要阅读纯文章，翻译体验会和以前差不多。如果你使用 LLM 翻译 GitHub、现代技术文档、仪表盘或 Tailwind 属性很多的网站，差异可能会非常明显：等待更短、超时更少、输入 token 也更少。

这次优化只应用于仅译文模式。双语翻译保持不变；如果译文已经命中缓存，本来就会很快，也不会再获得明显提升。

我们怎样测试

每次测试都通过生产构建扩展的后台翻译链路，并使用唯一缓存键。我们排除了一次预热请求，交替执行旧方案与新方案；LLM 场景重复 3 次，机器翻译场景重复 7 次。文中的时间是翻译服务请求耗时的中位数，不包括 DOM 扫描和最终页面渲染。

因此，14.9 倍描述的是测试中的 API 请求，不保证所有完整网页都会快 14.9 倍。整页速度还会受到段落拆分、批处理、并发、网络环境和缓存等因素影响。

如果你想了解实现讨论和完整的安全回退机制，可以查看 issue #1415 和 PR #1832。