Невидимый багаж веб-страницы
На экране страница может выглядеть как несколько аккуратных абзацев, но за ними скрываются тысячи символов: классы оформления, данные аналитики, ссылки, сведения об изображениях и другие инструкции для браузера.
Эти данные важны для страницы, но почти никогда не требуют перевода. Раньше режим «Только перевод» отправлял значительную часть такого багажа вместе с текстом. На современных сайтах с множеством компонентов переводчик мог тратить больше времени на устройство страницы, чем на саму фразу.
Версия 1.39.5 меняет это.
В самом насыщенном атрибутами тесте OpenAI один и тот же запрос сократился примерно с 19.1 секунды до 1.28 секунды — ускорение 14.9×.
Меньше данных в запросе, точное восстановление после перевода
Read Frog временно откладывает атрибуты, которым не нужен перевод, и оставляет на их месте короткий маркер. Провайдер переводит текст и HTML-структуру, а после ответа Read Frog восстанавливает исходные атрибуты и только затем показывает результат.
В обычном образце современной документации запрос стал на 69.8% меньше. В экстремальном образце в стиле Tailwind/GitHub — на 98.2% меньше.
Процесс состоит из трёх простых шагов:
- Сохранить видимый текст, HTML-структуру и текстовые атрибуты, которым может понадобиться перевод.
- Заменить стили, URL, ID и другие скрытые атрибуты маленькими маркерами только для этого запроса.
- Проверить каждый маркер и восстановить исходные атрибуты до показа перевода.
Если провайдер не сохранил маркеры правильно, Read Frog отклонит результат и безопасно вернётся к совместимому способу, а не вставит повреждённый HTML.
Результаты тестов с реальными API
Мы проверили собранное расширение на настоящих endpoint OpenAI, DeepSeek, Google, Microsoft и DeepL. Эффект сильно зависит от количества скрытых атрибутов внутри переводимого фрагмента.
Три колонки соответствуют простой статье, обычной современной документации и компонентной странице с очень большим количеством атрибутов.
| Тип страницы | Ожидаемый результат |
|---|---|
| Простая статья с малым числом атрибутов | Обычно почти без изменений |
| GitHub Issue или современная техническая документация | В образцах OpenAI 1.54×, DeepSeek 2.16× |
| Контент Next.js, Tailwind или множество компонентов | OpenAI достиг 14.9×; старый путь DeepSeek завершился тайм-аутом в 2 из 3 попыток |
В тяжёлом образце DeepSeek новый запрос стабильно завершался примерно за 1.25 секунды. Старый дважды завершился по тайм-ауту, а единственная успешная попытка заняла 45.5 секунды. Поскольку старый путь был нестабилен, мы не называем это устойчивым коэффициентом ускорения.
А машинный перевод?
Сервисы машинного перевода уже эффективно обрабатывают HTML, а постоянная сетевая задержка занимает большую долю времени. Поэтому разница оказалась меньше.
| Провайдер | Обычные страницы | Страницы с множеством атрибутов |
|---|---|---|
| Google Translate | Почти без изменений | Почти без изменений; разница в основном объясняется колебаниями сети |
| Microsoft Translator | Почти без изменений | 1.68× в экстремальном образце |
| DeepL | Почти без изменений | 1.06×, фактически без заметной разницы |
Даже если время почти не меняется, меньший запрос сокращает лишний трафик и вероятность упереться в ограничение размера.
Меньше входных token — ниже стоимость LLM
Переведённый текст и объём ответа почти не меняются, поэтому экономия возникает в основном за счёт ненужного ввода. С учётом фиксированного prompt и стоимости ответа мы оцениваем снижение цены всего вызова так:
- OpenAI: около 10–25% на обычных современных страницах и 80–90% на экстремально насыщенном атрибутами контенте.
- DeepSeek: около 20–35% на обычных современных страницах и 88–94% на экстремально насыщенном атрибутами контенте.
Это оценка по протестированным запросам и ценам, доступным 11 июля 2026 года, а не обещание для каждой страницы. Актуальные цены смотрите на официальных страницах OpenAI и DeepSeek.
Встроенные варианты Google и Microsoft не создают для пользователя счёт за API. У DeepL другая модель: при обработке HTML символы внутри тегов и атрибутов не тарифицируются, поэтому здесь оптимизация прежде всего уменьшает запрос и повышает надёжность.
Что вы заметите
Если вы в основном читаете простые статьи, ощущения останутся знакомыми. При переводе через LLM страниц GitHub, современной документации, панелей и сайтов с множеством Tailwind-атрибутов разница может быть значительной: меньше ожидания, тайм-аутов и входных token.
Оптимизация относится только к режиму «Только перевод». Двуязычный перевод не изменился, а перевод из кэша и так возвращается быстро, поэтому дополнительный эффект там минимален.
Наибольший выигрыш возникает, когда видимого текста мало, но содержащий его элемент несёт очень длинный список скрытых атрибутов.
Как мы измеряли
Все результаты прошли через фоновый путь production-сборки и использовали уникальный ключ кэша. Мы исключили один прогревочный запрос, чередовали порядок старого и нового вариантов, повторили LLM-тесты 3 раза, а машинный перевод — 7 раз. Указана медиана времени запроса к провайдеру без сканирования DOM и финального рендеринга.
Поэтому 14.9× относится к протестированному API-запросу и не гарантирует, что каждая целая страница завершится в 14.9× быстрее. Итоговое время также зависит от деления на абзацы, пакетирования, параллельности, сети и кэша.
Обсуждение реализации и защитных механизмов доступно в issue #1415 и PR #1832.
Написал
Read Frog Team
В
сб 11 июл. 2026 г.
Версия расширения
1.39.5