Решения для интернационализации являются одними из самых тяжелых зависимостей во 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) (vue-i18n@11.4.0):

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

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

(fluent-vue) (fluent-vue@0.5.0):

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

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

(Intlayer) (vue-intlayer@8.7.12):

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

TanStack

Solid