Решения для интернационализации являются одними из самых тяжелых зависимостей во Vue-приложении. Основной риск заключается в передаче ненужного контента: переводов для других страниц и других локалей в бандле одного маршрута.

По мере роста вашего приложения эта проблема может быстро привести к раздуванию JavaScript, отправляемого клиенту, и замедлению навигации.

На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.

Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.

TL;DR

Intlayer: Самое легкое решение (v8.7.12) со встроенным разделением (scoping) и динамической загрузкой.
vue-i18n: Индустриальный стандарт с богатой экосистемой, но может быть значительно тяжелее и сложнее в оптимизации для разделения кода в больших приложениях.
fluent-vue: Инновационная организация сообщений, но не хватает типобезопасности и является чрезвычайно тяжелым решением.

Проверьте свое приложение

Чтобы быстро выявить проблемы с утечкой i18n, я настроил бесплатный сканер, доступный здесь.

intlayer.org

Проблема

Два рычага необходимы для ограничения стоимости мультиязычного приложения:

Разделение контента по страницам / пространствам имен, чтобы не загружать целые словари, когда они вам не нужны.
Динамическая загрузка нужной локали только тогда, когда она требуется.

Понимание технических ограничений этих подходов:

Динамическая загрузка

Без динамической загрузки большинство решений хранят сообщения в памяти с первого рендеринга, что создает значительные накладные расходы для приложений с множеством маршрутов и локалей.

При использовании динамической загрузки вы идете на компромисс: меньше начального JS, но иногда дополнительный запрос при переключении языка.

Разделение контента

Синтаксис, построенный вокруг const { t } = useI18n() + t('a.b.c'), очень удобен, но часто способствует хранению больших JSON-объектов во время выполнения. Эта модель затрудняет tree-shaking, если библиотека не предлагает реальную стратегию разделения контента для каждой страницы.

Методология

Для этого бенчмарка мы сравнили следующие библиотеки:

Base App (Без библиотеки i18n)
vue-intlayer (v8.7.12)
vue-i18n (v11.4.0)
fluent-vue (v3.8.2)

Фреймворк - Vue с мультиязычным приложением из 10 страниц и 10 языков.

Мы сравнили четыре стратегии загрузки:

Показать все данные таблицы

Открыть таблицу в модальном окне для четкого просмотра всех данных

Стратегия	Без пространств имен (глобальная)	С пространствами имен (локальная/scoped)
Статическая загрузка	Static: Все в памяти при запуске.	Scoped static: Разделено по пространствам имен; все загружается при запуске.
Динамическая загрузка	Dynamic: Загрузка по требованию для локали.	Scoped dynamic: Гранулярная загрузка по пространствам имен и локалям.

Резюме стратегий

Статическая (Static): Простота; отсутствие задержек сети после начальной загрузки. Минус: большой размер бандла.
Динамическая (Dynamic): Уменьшает начальный вес (ленивая загрузка). Идеально при наличии множества локалей.
Локальная статическая (Scoped static): Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
Локальная динамическая (Scoped dynamic): Лучший подход для разделения кода и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.

Что я вимірював:

Я запускал одно и то же мультиязычное приложение в реальном браузере для каждого стека, а затем фиксировал, что на самом деле передавалось по сети и сколько времени это занимало. Размеры указаны после обычного веб-сжатия, так как это ближе к тому, что люди реально скачивают.

Размер библиотеки интернационализации: После сборки, tree-shaking и минификации, размер библиотеки i18n - это размер кода провайдеров + композиблов (composables) в пустом компоненте. Это не включает загрузку файлов перевода. Это показывает, насколько "дорогая" библиотека еще до появления вашего контента.
JavaScript на страницу: Для каждого тестового маршрута - сколько скриптов загружает браузер во время посещения, усреднено по страницам теста (и по локалям). Тяжелые страницы - это медленные страницы.
Утечка из других локалей (Leakage): Это контент той же страницы, но на другом языке, который по ошибке загружается на проверяемую страницу. Этот контент является лишним и его следует избегать (например, контент страницы /fr/about в бандле страницы /en/about).
Утечка из других маршрутов: Та же идея для других экранов в приложении: передаются ли их тексты, когда вы открыли только одну страницу (например, контент страницы /en/about в бандле страницы /en/contact). Высокий показатель свидетельствует о слабом разделении или слишком широких бандлах.
Средний размер бандла компонента: Отдельные UI-элементы измеряются по одному, а не прячутся внутри одного гигантского общего показателя приложения. Это показывает, "раздувает" ли интернационализация обычные компоненты. Например, если ваш компонент перерендерится, он будет загружать все эти данные из памяти. Привязка гигантского JSON к любому компоненту похожа на подключение большого хранилища неиспользуемых данных, что замедляет производительность ваших компонентов.
Скорость реакции на переключение языка: Я переключаю язык через собственный интерфейс приложения и замеряю время до момента, когда страница явно обновилась - то, что заметит посетитель.
Работа рендеринга после смены языка: Более узкий показатель: сколько усилий затратил интерфейс на перерисовку для нового языка после начала переключения. Полезно, когда "ощутимое" время и стоимость работы фреймворка различаются.
Время начальной загрузки страницы: От навигации до момента, когда браузер считает страницу полностью загруженной для тестируемых сценариев. Полезно для сравнения "холодных стартов".
Время гидратации (Hydration): Время, которое клиент тратит на превращение HTML от сервера в интерактивный интерфейс. Прочерк в таблицах означает, что данная реализация не предоставила надежных данных о гидратации в этом тесте.

Звезды на GitHub

Звезды на GitHub - это сильный индикатор популярности проекта, доверия сообщества и долгосрочной актуальности. Хотя они не являются прямым показателем технического качества, они отражают, сколько разработчиков считают проект полезным, следят за его прогрессом и, вероятно, будут его использовать. Для оценки ценности проекта звезды помогают сравнивать популярность альтернатив и дают представление о росте экосистемы.

Результаты в деталях

1 - Решения, которых следует избегать

В экосистеме Vue нет однозначных решений, которых следует избегать.

2 - Приемлемые решения

(vue-i18n) ([email protected]):

vue-i18n, без сомнения, является самой используемой i18n-библиотекой для Vue, у нее много функций и огромная экосистема. Однако внутри это решение довольно тяжелое. Даже если vue-i18n интегрирует ленивую загрузку сообщений, в нем отсутствует функция разделения (scoping). В случае классического Vue SPA приложения это не проблема, но для приложения Nuxt, использующего @nuxt/i18n, это приводит к включению сообщений со всех страниц в одну. Для большого приложения Nuxt, включающего более 10 страниц, это может стать действительно проблематичным.

Пакет очень тяжелый (~24.3 КБ, что примерно в 9 раз больше vue-intlayer).

(fluent-vue) ([email protected]):

fluent-vue предлагает попытку инновации через формат .ftl. Организация сообщений отличная, с ней легче начать работу. Но на практике отсутствие типобезопасности повышает риск ошибок и может быстро стать трудозатратным при отладке. Более того, это решение загружает сообщения с помощью плагина vite, который принудительно загружает весь контент на всех языках в каждую страницу. Кроме того, это чрезвычайно тяжелое решение (~92.7 КБ, что примерно в 34 раза больше vue-intlayer).

3 - Рекомендации

(Intlayer) ([email protected]):

Я не буду лично оценивать vue-intlayer ради объективности, так как это мое собственное решение.

TanStack

Solid

Автор: Aymeric PINEAU

Создание:2026-04-20Последнее обновление:2026-05-18

Посмотреть шаблон приложения на GitHub

Для этой страницы доступен шаблон приложения.

Ссылайтесь на этот документ на ваш любимый ассистент AI

ChatGPT

Claude

DeepSeek

Google AI mode Gemini

Perplexity Mistral

Grok

Спросите свой вопрос и получите сводку документа, используя эту страницу и выбранного вами поставщика AI

История версий

"Добавить сравнение звезд GitHub"
v8.9.818.05.2026
"Инициализация бенчмарка"
v8.7.1206.01.2026

Содержимое этой страницы было переведено с помощью ИИ.

Смотреть последнюю версию оригинального контента на английском

Изменить эту документацию

Ссылка на документацию GitHub

Копировать

Копировать Markdown документа в буфер обмена

Библиотеки i18n для Vue - Отчет о бенчмарке 2026

Эта страница представляет собой отчет о бенчмарке i18n-решений для Vue.

Содержание

Интерактивный бенчмарк

Динамическая загрузка JSON

Ленивая загрузка переводов во время выполнения

Ограниченный JSON (пространства имен)

Пространства имен перевода для каждой страницы

Бенчмарк производительности I18n

Нет данных

Что это за метрика?

Общий размер пакета библиотеки интернационализации в формате gzip. Он включает в себя только провайдер и логику извлечения контента после tree-shaking и минификации.

Почему это важно?

Меньший размер библиотеки снижает начальную загрузку JavaScript, что ускоряет загрузку и выполнение кода на клиенте.

Вид

Ссылка на результаты:

intlayer.org

Посмотреть полные данные бенчмарка

Полный репозиторий бенчмарка можно найти здесь.

Введение

TL;DR

Intlayer: Самое легкое решение (v8.7.12) со встроенным разделением (scoping) и динамической загрузкой.
vue-i18n: Индустриальный стандарт с богатой экосистемой, но может быть значительно тяжелее и сложнее в оптимизации для разделения кода в больших приложениях.
fluent-vue: Инновационная организация сообщений, но не хватает типобезопасности и является чрезвычайно тяжелым решением.

Проверьте свое приложение

Чтобы быстро выявить проблемы с утечкой i18n, я настроил бесплатный сканер, доступный здесь.

intlayer.org

Проблема

Два рычага необходимы для ограничения стоимости мультиязычного приложения:

Разделение контента по страницам / пространствам имен, чтобы не загружать целые словари, когда они вам не нужны.
Динамическая загрузка нужной локали только тогда, когда она требуется.

Понимание технических ограничений этих подходов:

Динамическая загрузка

Разделение контента

Методология

Для этого бенчмарка мы сравнили следующие библиотеки:

Base App (Без библиотеки i18n)
vue-intlayer (v8.7.12)
vue-i18n (v11.4.0)
fluent-vue (v3.8.2)

Фреймворк - Vue с мультиязычным приложением из 10 страниц и 10 языков.

Мы сравнили четыре стратегии загрузки:

Показать все данные таблицы

Открыть таблицу в модальном окне для четкого просмотра всех данных

Стратегия	Без пространств имен (глобальная)	С пространствами имен (локальная/scoped)
Статическая загрузка	Static: Все в памяти при запуске.	Scoped static: Разделено по пространствам имен; все загружается при запуске.
Динамическая загрузка	Dynamic: Загрузка по требованию для локали.	Scoped dynamic: Гранулярная загрузка по пространствам имен и локалям.

Резюме стратегий

Статическая (Static): Простота; отсутствие задержек сети после начальной загрузки. Минус: большой размер бандла.
Динамическая (Dynamic): Уменьшает начальный вес (ленивая загрузка). Идеально при наличии множества локалей.
Локальная статическая (Scoped static): Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
Локальная динамическая (Scoped dynamic): Лучший подход для разделения кода и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.

Что я вимірював:

Размер библиотеки интернационализации: После сборки, tree-shaking и минификации, размер библиотеки i18n - это размер кода провайдеров + композиблов (composables) в пустом компоненте. Это не включает загрузку файлов перевода. Это показывает, насколько "дорогая" библиотека еще до появления вашего контента.
JavaScript на страницу: Для каждого тестового маршрута - сколько скриптов загружает браузер во время посещения, усреднено по страницам теста (и по локалям). Тяжелые страницы - это медленные страницы.
Утечка из других локалей (Leakage): Это контент той же страницы, но на другом языке, который по ошибке загружается на проверяемую страницу. Этот контент является лишним и его следует избегать (например, контент страницы /fr/about в бандле страницы /en/about).
Утечка из других маршрутов: Та же идея для других экранов в приложении: передаются ли их тексты, когда вы открыли только одну страницу (например, контент страницы /en/about в бандле страницы /en/contact). Высокий показатель свидетельствует о слабом разделении или слишком широких бандлах.
Средний размер бандла компонента: Отдельные UI-элементы измеряются по одному, а не прячутся внутри одного гигантского общего показателя приложения. Это показывает, "раздувает" ли интернационализация обычные компоненты. Например, если ваш компонент перерендерится, он будет загружать все эти данные из памяти. Привязка гигантского JSON к любому компоненту похожа на подключение большого хранилища неиспользуемых данных, что замедляет производительность ваших компонентов.
Скорость реакции на переключение языка: Я переключаю язык через собственный интерфейс приложения и замеряю время до момента, когда страница явно обновилась - то, что заметит посетитель.
Работа рендеринга после смены языка: Более узкий показатель: сколько усилий затратил интерфейс на перерисовку для нового языка после начала переключения. Полезно, когда "ощутимое" время и стоимость работы фреймворка различаются.
Время начальной загрузки страницы: От навигации до момента, когда браузер считает страницу полностью загруженной для тестируемых сценариев. Полезно для сравнения "холодных стартов".
Время гидратации (Hydration): Время, которое клиент тратит на превращение HTML от сервера в интерактивный интерфейс. Прочерк в таблицах означает, что данная реализация не предоставила надежных данных о гидратации в этом тесте.

Звезды на GitHub

Результаты в деталях

1 - Решения, которых следует избегать

В экосистеме Vue нет однозначных решений, которых следует избегать.

2 - Приемлемые решения

(vue-i18n) ([email protected]):

vue-i18n, без сомнения, является самой используемой i18n-библиотекой для Vue, у нее много функций и огромная экосистема. Однако внутри это решение довольно тяжелое. Даже если vue-i18n интегрирует ленивую загрузку сообщений, в нем отсутствует функция разделения (scoping). В случае классического Vue SPA приложения это не проблема, но для приложения Nuxt, использующего @nuxt/i18n, это приводит к включению сообщений со всех страниц в одну. Для большого приложения Nuxt, включающего более 10 страниц, это может стать действительно проблематичным.

Пакет очень тяжелый (~24.3 КБ, что примерно в 9 раз больше vue-intlayer).

(fluent-vue) ([email protected]):

fluent-vue предлагает попытку инновации через формат .ftl. Организация сообщений отличная, с ней легче начать работу. Но на практике отсутствие типобезопасности повышает риск ошибок и может быстро стать трудозатратным при отладке. Более того, это решение загружает сообщения с помощью плагина vite, который принудительно загружает весь контент на всех языках в каждую страницу. Кроме того, это чрезвычайно тяжелое решение (~92.7 КБ, что примерно в 34 раза больше vue-intlayer).

3 - Рекомендации

(Intlayer) ([email protected]):

Я не буду лично оценивать vue-intlayer ради объективности, так как это мое собственное решение.

TanStack

Solid