訳文のみ翻訳が最大 14.9× 高速に

ページの裏にある、見えない荷物

画面では数段落しか見えないページでも、裏側にはスタイル用 class、計測データ、リンク、画像情報など、読者には見えない何千もの文字が含まれています。

これらはページ表示には必要ですが、ほとんどは翻訳不要です。これまで訳文のみモードでは、その隠れた情報の多くも本文と一緒に翻訳サービスへ送っていました。コンポーネントの多い現代的なサイトでは、翻訳対象の文章よりページの仕組みを読むほうに時間がかかることさえありました。

バージョン 1.39.5 では、この無駄を減らします。

送信量を減らし、戻ってきたら完全に復元

Read Frog は翻訳不要な属性を一時的に退避し、その場所だけを短いマーカーで覚えます。プロバイダーは文字と HTML 構造を翻訳し、結果が戻ると Read Frog が元の属性を復元してからページに表示します。

通常のモダンなドキュメントではリクエストが 69.8% 小さくなり、極端な Tailwind/GitHub 形式のサンプルでは 98.2% 小さくなりました。

仕組みは三段階です。

1. 表示される文章、HTML 構造、翻訳が必要な文字属性を残す。
2. スタイル、URL、ID などを、そのリクエスト専用の小さなマーカーに置き換える。
3. すべてのマーカーを検証し、元の属性を復元してから訳文を表示する。

プロバイダーがマーカーを正しく保てなかった場合、Read Frog は壊れた HTML を挿入せず、その結果を拒否して安全な方式へフォールバックします。

実際の API で得られた結果

ビルド済み拡張機能から OpenAI、DeepSeek、Google、Microsoft、DeepL の実際のエンドポイントをテストしました。効果は、翻訳する区間に隠れたページ属性がどれだけ含まれるかで大きく変わります。

三列は、シンプルな記事、通常のモダンドキュメント、属性が非常に多いコンポーネントページを表します。

DeepSeek の高密度サンプルでは、新方式は約 1.25 秒で安定しました。旧方式は 2 回タイムアウトし、唯一成功した試行も 45.5 秒でした。旧方式が不安定なため、安定した高速化倍率としては掲載していません。

機械翻訳では？

機械翻訳サービスはもともと HTML 処理が速く、固定の通信時間が大きいため、速度差は小さくなりました。

時間差が小さくても、リクエストが小さくなることで不要な通信やサイズ制限に達する可能性を減らせます。

入力 token が減れば、LLM コストも下がる

出力される訳文はほぼ同じなので、節約の中心は不要な入力の削減です。固定プロンプトと出力料金も含めた呼び出し全体の推定削減率は次のとおりです。

• OpenAI: 通常のモダンなページで約 10–25%、極端な属性密集ページで 80–90%。
• DeepSeek: 通常のモダンなページで約 20–35%、極端な属性密集ページで 88–94%。

これはテストした送信量と 2026 年 7 月 11 日時点の料金に基づく推定で、すべてのページを保証するものではありません。最新料金は OpenAI と DeepSeek の公式ページをご確認ください。

Read Frog 内蔵の Google と Microsoft は、ユーザーに API 料金を発生させません。DeepL は HTML 処理時にタグや属性内の文字を課金対象にしていないため、今回の効果は料金より送信量と信頼性に表れます。

実際に感じられること

主にプレーンな記事を読む場合は、これまでとほぼ同じです。LLM で GitHub、モダンな技術文書、ダッシュボード、Tailwind の属性が多いサイトを翻訳する場合は、待ち時間、タイムアウト、入力 token のすべてで大きな差が出る可能性があります。

この最適化は訳文のみモードが対象です。バイリンガル翻訳は変わりません。キャッシュにある翻訳もすでに高速なため、追加効果はほとんどありません。

測定方法

本番ビルドのバックグラウンド翻訳経路と毎回異なるキャッシュキーを使いました。ウォームアップ 1 回を除外し、新旧の実行順を交互に変更。LLM は 3 回、機械翻訳は 7 回繰り返し、中間値を採用しました。時間には DOM 走査と最終描画を含みません。

つまり、14.9× はテストした API リクエストの結果で、すべてのページ全体が 14.9× 速くなる保証ではありません。ページ全体の時間は分割、バッチ、同時実行数、通信、キャッシュにも左右されます。

実装と安全なフォールバックの詳細は issue #1415 と PR #1832 をご覧ください。