The invisible baggage behind a web page
A page can look like a few clean paragraphs while carrying thousands of characters you never see: style classes, tracking data, links, image details, and other instructions for the browser.
Those details matter to the page, but most of them do not need translation. In translation-only mode, Read Frog used to send much of that hidden baggage together with the words. On modern, component-heavy websites, the translator could spend more time reading page machinery than translating the sentence in front of you.
Version 1.39.5 changes that.
In our most attribute-heavy OpenAI test, the same translation request went from about 19.1 seconds to 1.28 seconds—a 14.9× speedup.
Much less data, with the page put back exactly as it was
Read Frog now temporarily sets aside attributes that do not need translation. A compact marker keeps their place while the provider translates the words and HTML structure. When the translation returns, Read Frog restores the original attributes before showing the result.
In a normal modern documentation sample, the request became 69.8% smaller. In an extreme Tailwind/GitHub-style sample, it became 98.2% smaller.
The process is intentionally simple:
- Keep the visible words, HTML structure, and text-like attributes that may need translation.
- Replace styling, URLs, IDs, and other hidden attributes with tiny markers held only for that request.
- Validate every marker and restore the original attributes before the translated page appears.
If a provider does not preserve the markers correctly, Read Frog rejects that result and safely falls back instead of inserting damaged HTML.
What the real API tests showed
We tested the built extension against real OpenAI, DeepSeek, Google, Microsoft, and DeepL endpoints. The improvement depends strongly on how much hidden page markup a translation segment contains.
The three columns represent a simple article, a normal modern document, and an attribute-heavy component page.
| Page type | What you can expect |
|---|---|
| Simple article with few attributes | Usually about the same speed |
| GitHub issue or modern documentation | OpenAI 1.54×, DeepSeek 2.16× in our samples |
| Next.js, Tailwind, or component-heavy content | OpenAI reached 14.9×; the old DeepSeek path timed out in 2 of 3 trials |
For the heavy DeepSeek sample, the new request completed consistently around 1.25 seconds. The old request timed out twice, and its only successful trial took 45.5 seconds. Because the old path was unreliable, we do not present that as a stable speedup number.
What about machine translation?
Machine translation services already process HTML efficiently, and fixed network time is a larger part of their response time. Their gains were therefore smaller:
| Provider | Normal pages | Attribute-heavy pages |
|---|---|---|
| Google Translate | About the same | Roughly the same; measured differences were mostly network noise |
| Microsoft Translator | About the same | 1.68× in the extreme sample |
| DeepL | About the same | 1.06×, effectively unchanged |
Smaller requests still reduce unnecessary traffic and lower the chance of hitting request-size limits, even when the stopwatch barely moves.
Fewer input tokens also means lower LLM cost
The translated words and output stay almost the same, so the savings come mainly from removing unnecessary input. After accounting for the fixed prompt and output cost, we estimate the following whole-request reductions:
- OpenAI: about 10–25% on normal modern pages and 80–90% on extreme attribute-heavy content.
- DeepSeek: about 20–35% on normal modern pages and 88–94% on extreme attribute-heavy content.
These are estimates based on the tested payloads and provider pricing available on July 11, 2026, not a promise for every page. See the official pricing pages for OpenAI and DeepSeek for current rates.
Read Frog's built-in Google and Microsoft options do not create a user API bill. DeepL is different again: with HTML handling enabled, DeepL does not bill the characters inside HTML tags or their attributes, so this optimization mainly improves payload size and reliability there rather than cost.
What you will notice
If you mostly read plain articles, translation should feel familiar. If you translate GitHub, modern documentation, dashboards, or Tailwind-heavy sites with an LLM, the difference can be substantial: less waiting, fewer timeouts, and fewer input tokens.
This optimization applies to translation-only mode. Bilingual translation is unchanged, and a cached translation is already fast enough that there is little additional benefit.
The biggest gains appear where the visible text is short but the page element carrying it has a very long list of hidden attributes.
How we measured it
Each result used the production extension's background translation path and a unique cache key. We excluded one warm-up request, alternated the old/new order, repeated LLM cases three times, and repeated machine-translation cases seven times. The figures report median provider-request time and exclude DOM scanning and final page rendering.
That means 14.9× describes the tested API request, not a guarantee that every full page finishes 14.9× sooner. Full-page time also depends on paragraph splitting, batching, concurrency, network conditions, and caching.
For the implementation discussion and complete safety behavior, see issue #1415 and PR #1832.
Written by
Read Frog Team
At
Sat Jul 11 2026
Extension Version
1.39.5