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

З ростом вашого додатка ця проблема може швидко збільшити обсяг JavaScript, що надсилається клієнту, і сповільнити навігацію.

На практиці, для найменш оптимізованих реалізацій, інтернаціоналізована сторінка може виявитися в кілька разів важчою, ніж версія без i18n.

Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організацію просторів імен, динамічне завантаження та реактивність при зміні локалі.

TL;DR

Intlayer: Найлегше рішення (v8.7.12) з нативним скоупінгом (scoping) та динамічним завантаженням.
vue-i18n: Галузевий стандарт з багатою екосистемою, але може стати значно важчим і важчим для оптимізації під code-splitting у великих додатках.
fluent-vue: Інноваційна організація повідомлень, але не вистачає безпеки типів (type-safety) і виявляється надзвичайно важким рішенням.

Протестуйте свій додаток

Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний тут.

intlayer.org

Проблема

Два важелі є важливими для обмеження вартості багатомовного додатка:

Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.

Розуміння технічних обмежень цих підходів:

Динамічне завантаження

Без динамічного завантаження більшість рішень зберігають повідомлення в пам'яті з першого рендеру, що додає значне навантаження для додатків з багатьма маршрутами та локалями.

З динамічним завантаженням ви приймаєте компроміс: менше початкового JS, але іноді додатковий запит при зміні мови.

Поділ контенту (Splitting)

Синтаксис, побудований навколо 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: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
Scoped static: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
Scoped dynamic: Найкращий підхід для code splitting та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.

Що я вимірював:

Я запустив той самий багатомовний додаток у реальному браузері для кожного стека, а потім записав, що насправді пройшло мережею і скільки часу це зайняло. Розміри вказані після звичайного веб-стиснення, оскільки це ближче до того, що люди насправді завантажують, ніж необроблена кількість рядків вихідного коду.

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

Зірки на GitHub

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

Результати детально

1 - Рішення, яких слід уникати

В екосистемі Vue немає очевидних рішень, яких слід уникати.

2 - Прийнятні рішення

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

vue-i18n безперечно є найбільш використовуваною бібліотекою i18n для Vue, вона має багато функцій і величезну екосистему. Але "під капотом" рішення досить важке. Навіть якщо vue-i18n інтегрує lazy loading для повідомлень, у ній відсутня функція скоупінгу (scoping). У випадку класичного Vue SPA додатка проблем немає, але для nuxt додатка, що використовує @nuxt/i18n, це призводить до включення повідомлень з усіх сторінок в одну. Для великого nuxt додатка з понад 10 сторінками це може стати справді проблематичним.

Пакет дуже важкий (~24.3kb, що приблизно в 9 разів більше за vue-intlayer).

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

fluent-vue пропонує спробу інновації через формат .ftl. Організація повідомлень чудова, легше почати роботу. Але на практиці відсутність безпеки типів підвищує ризик помилок і налагодження може швидко стати трудомістким. Більше того, це рішення завантажує повідомлення за допомогою плагіна vite, який змушує завантажувати весь контент усіма мовами на кожну сторінку. Крім того, це надзвичайно важке рішення (~92.7kb, що приблизно в 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

Історія версій

"Додати порівняння зірок GitHub"
v8.9.818.05.2026
"Ініціалізація бенчмарку"
v8.7.1206.01.2026

Вміст цієї сторінки перекладено за допомогою штучного інтелекту.

Переглянути останню версію оригінального вмісту англійською

Редагувати цей документ

Якщо у вас є ідея щодо покращення цієї документації, будь ласка, долучіться, надіславши pull request на GitHub.

Посилання на документацію на 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: Галузевий стандарт з багатою екосистемою, але може стати значно важчим і важчим для оптимізації під code-splitting у великих додатках.
fluent-vue: Інноваційна організація повідомлень, але не вистачає безпеки типів (type-safety) і виявляється надзвичайно важким рішенням.

Протестуйте свій додаток

Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний тут.

intlayer.org

Проблема

Два важелі є важливими для обмеження вартості багатомовного додатка:

Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.

Розуміння технічних обмежень цих підходів:

Динамічне завантаження

Поділ контенту (Splitting)

Методологія дослідження

Для цього бенчмарку ми порівняли наступні бібліотеки:

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: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
Scoped static: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
Scoped dynamic: Найкращий підхід для code splitting та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.

Що я вимірював:

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

Зірки на GitHub

Результати детально

1 - Рішення, яких слід уникати

В екосистемі Vue немає очевидних рішень, яких слід уникати.

2 - Прийнятні рішення

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

vue-i18n безперечно є найбільш використовуваною бібліотекою i18n для Vue, вона має багато функцій і величезну екосистему. Але "під капотом" рішення досить важке. Навіть якщо vue-i18n інтегрує lazy loading для повідомлень, у ній відсутня функція скоупінгу (scoping). У випадку класичного Vue SPA додатка проблем немає, але для nuxt додатка, що використовує @nuxt/i18n, це призводить до включення повідомлень з усіх сторінок в одну. Для великого nuxt додатка з понад 10 сторінками це може стати справді проблематичним.

Пакет дуже важкий (~24.3kb, що приблизно в 9 разів більше за vue-intlayer).

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

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

3 - Рекомендації

(Intlayer) ([email protected]):

Я не буду особисто оцінювати vue-intlayer заради об'єктивності, оскільки це моє власне рішення.

TanStack

Solid