僅譯文翻譯，最高快 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。