---
createdAt: 2026-04-20
updatedAt: 2026-05-18
title: Найкраще i18n рішення для Vue у 2026 році - Звіт про бенчмарк
description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Vue, такі як vue-i18n, fluent-vue та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
keywords:
  - benchmark
  - i18n
  - intl
  - vue
  - продуктивність
  - intlayer
slugs:
  - doc
  - benchmark
  - vue
author: Aymeric PINEAU
applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
history:
  - version: 8.9.8
    date: 2026-05-18
    changes: "Додати порівняння зірок GitHub"
  - version: 8.7.12
    date: 2026-01-06
    changes: "Ініціалізація бенчмарку"
---

# Бібліотеки i18n для Vue - Звіт про бенчмарк 2026

Ця сторінка є звітом про бенчмарк рішень i18n на Vue.

## Зміст

<Toc/>

## Інтерактивний бенчмарк

<I18nBenchmark framework="vite-vue" vertical/>

## Посилання на результати:

<ClickToOpenIframe
src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
width="100%"
height="600px"
style="border:none;"
/>

> [Переглянути повні дані бенчмарку](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md)

Повний репозиторій бенчмарку можна знайти [тут](https://github.com/intlayer-org/benchmark-i18n/tree/main).

## Вступ

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

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

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

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

## TL;DR

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

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

Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний [тут](https://intlayer.org/i18n-seo-scanner).

<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>

## Проблема

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

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

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

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

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

З динамічним завантаженням ви приймаєте компроміс: менше початкового 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 є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.

[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Cfluent-vue%2Ffluent-vue%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#intlify/vue-i18n&fluent-vue/fluent-vue&aymericzip/intlayer)

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

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

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

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

**(vue-i18n)** (`vue-i18n@11.4.0`):

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

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

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

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

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

**(Intlayer)** (`vue-intlayer@8.7.12`):

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