@intlayer/docs 9.5.6 → 9.5.8

package/blog/pl/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark i porównanie 2026"
 description: "react-i18next i next-i18next w porównaniu z Intlayer na Next.js i TanStack Start. Rozmiar bundle, wycieki treści, czas reakcji przy zmianie języka i doświadczenie programisty."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` to najczęściej używany framework i18n w ekosystemie JavaScript. Poprzez `react-i18next` i `next-i18next` zasila ogromną część aplikacji React i Next.js. Intlayer to nowoczesna alternatywa oparta na kompilatorze i izolacji na poziomie komponentów.
 
 Ten artykuł porównuje oba rozwiązania na podstawie twardych pomiarów, a nie list funkcji. Liczby pochodzą z [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), otwartoźródłowego pakietu testów, który buduje tę samą aplikację z każdą biblioteką i rejestruje, co przeglądarka faktycznie pobiera.
@@ -99,6 +101,10 @@ Dla każdego buildu rejestrowane są wskaźniki:
 
 ### Wyniki w Next.js (`next-i18next`)
 
+Wybierz metryki i biblioteki, które Cię interesują:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteka                        | Strategia      | Lib size (gz) | Page JS avg (gz) | Wyciek języka | Wyciek strony | Komponent śr. (gz) | Reaktywność E2E | Hydratacja |
 | --------------------------------- | -------------- | ------------: | ---------------: | ------------: | ------------: | -----------------: | --------------: | ---------: |
 | **base** (bez i18n)               | -              |        0.0 KB |         141.0 KB |          0.0% |          0.0% |             0.9 KB |         13.4 ms |    11.8 ms |
@@ -119,6 +125,15 @@ Dla każdego buildu rejestrowane są wskaźniki:
 - **Wielkość komponentów**: Komponent wywołujący `useTranslation()` kompiluje się do 26-79 KB; ten sam komponent z `useIntlayer()` zajmuje zaledwie 6.9 KB.
 - **Czas hydratacji**: w konfiguracji `dynamic` wzrasta do 27.7 ms, ponieważ instancja i18next musi zainicjalizować się i przetworzyć backend po stronie klienta, zanim React ukończy hydratację.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Pełna tabela, każda biblioteka i każda strategia, w [raporcie benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs).
+
 ### Wyniki w TanStack Start (`react-i18next`)
 
 Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje specyfikę Next.js z testu porównawczego.
@@ -141,8 +156,19 @@ Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje spec
 - Intlayer w trybie `static` wykazuje **0% wycieku stron** już na starcie, ponieważ pakowane są tylko te słowniki, które zostały zaimportowane przez komponenty danej strony. Włączenie `importMode: 'dynamic'` eliminuje także wyciek języka.
 - **Rozmiar komponentu**: 24-27 KB w `react-i18next` wobec 6-8 KB w Intlayer. `useTranslation()` wiąże każdy komponent z globalną instancją i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Pełna tabela w [raporcie benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack).
+
 ## Skąd ta różnica? Globalna instancja vs skompilowane słowniki
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` powstał w 2012 roku jako runtime: pojedyncza globalna instancja trzyma repozytorium zasobów, wtyczki je rozszerzają, a `t()` szuka kluczy w czasie renderowania. Daje to wszechstronność, ale generuje narzut:
 
 ```bash
@@ -166,7 +192,13 @@ Ta sama aplikacja na TanStack Start z czystym `react-i18next`, co eliminuje spec
                 └── page.tsx     # musi wiedzieć, że potrzebuje ["common", "about"]
 ```
 
-Instancja nie wie z góry, o jakie klucze zapyta komponent, dlatego trzyma wszystkie przestrzenie nazw przekazane do załadowania. Optymalizacja wymaga, aby **programista** dzielił katalogi, wyliczał przestrzenie dla każdej strony i na bieżąco korygował te powiązania. Jak zauważono w [notatkach z benchmarku](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Utrzymanie typowania i dokładna wiedza o tym, który namespace dołączyć do danej strony, to koszmar".
+Instancja nie wie z góry, o jakie klucze zapyta komponent, dlatego trzyma wszystkie przestrzenie nazw przekazane do załadowania. Optymalizacja wymaga, aby **programista** dzielił katalogi, wyliczał przestrzenie dla każdej strony i na bieżąco korygował te powiązania.
+
+Koszt rośnie w dwóch wymiarach jednocześnie, stron i języków:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Jak zauważono w [notatkach z benchmarku](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Utrzymanie typowania i dokładna wiedza o tym, który namespace dołączyć do danej strony, to koszmar".
 
 Intlayer eliminuje instancję globalną. Treści deklarowane są tuż obok komponentu, a kompilator rozwiązuje graf zależności podczas budowania:
 
@@ -193,7 +225,8 @@ Intlayer eliminuje instancję globalną. Treści deklarowane są tuż obok kompo
 
 ### Konfiguracja
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Do tego dochodzi kliencki `I18nProvider`, `generateStaticParams` oraz deklarowanie tablicy `namespaces` na każdej podstronie.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Komponent kliencki
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Strona renderująca ten komponent musi załadować namespace `about`, a `t("counter.label")` pozostaje zwykłym stringiem bez rozszerzenia `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 Pola `label` oraz `increment` posiadają ścisłe typowanie; każda literówka natychmiast generuje błąd TypeScript, a brak tłumaczenia dla języka francuskiego zablokuje proces budowania.
 
+</Tab>
+</Tabs>
+
 ### Synchroniczny komponent serwerowy (RSC)
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Na poziomie strony wywołuje się `i18n.getFixedT(locale, "about")`, po czym przekazuje `t` i `locale` w dół za pomocą props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Zachowaj API i18next, zyskaj wydajność Intlayer
 
 Nie musisz przepisywać istniejących komponentów, aby cieszyć się zyskami z powyższego benchmarku. Adaptery `@intlayer/i18next`, `@intlayer/react-i18next` i `@intlayer/next-i18next` działają bezpośrednio jako zamienniki typu drop-in: wywołania `useTranslation`, `t()`, `<Trans>`, obsługa liczb mnogich i kontekstów działają bez zmian, serwowane przez zoptymalizowane słowniki Intlayer.
@@ -415,18 +462,85 @@ Zobacz przewodniki migracji: [i18next](https://intlayer.org/pl/doc/migration/i18
 
 ## Kiedy wybrać dane rozwiązanie?
 
-- **Wybierz i18next**: jeśli bezwzględnie wymagasz jego ekosystemu wtyczek (specyficzne detektory, niestandardowe backendy, ICU, Locize), lokalizujesz treści także poza środowiskiem React (serwisy Node, czysty JS, inne frameworki), zespół ma już opanowane narzędzia lub zewnętrzna platforma tłumaczeniowa wymaga struktury `locales/{lng}/{ns}.json`. Zadbaj o czas na ręczną organizację przestrzeni nazw i mapowanie tras.
-- **Wybierz Intlayer**: jeśli zależy Ci na **treściach przypisanych bezpośrednio do komponentów**, **ścisłym bezpieczeństwie TypeScript**, **wykrywaniu brakujących kluczy podczas budowania**, **automatycznym tree-shakingu i leniwym ładowaniu bez wysiłku**, natychmiastowej zmianie języka, synchronicznych komponentach serwerowych i zintegrowanych narzędziach (Edytor Wizualny, CMS, tłumaczenie AI, serwer MCP). Znakomity wybór dla aplikacji modułowych i systemów projektowych (Design Systems).
-- **Wybierz adaptery `@intlayer/*-i18next`**: jeśli posiadasz istniejący kod oparty na i18next i chcesz natychmiast zredukować wagę paczki oraz przyspieszyć działanie bez konieczności refaktoryzacji.
+<AccordionGroup>
+<Accordion header="Wybierz i18next">
+
+Jeśli bezwzględnie wymagasz jego ekosystemu wtyczek (specyficzne detektory, niestandardowe backendy, ICU, Locize), lokalizujesz treści także poza środowiskiem React (serwisy Node, czysty JS, inne frameworki), zespół ma już opanowane narzędzia lub zewnętrzna platforma tłumaczeniowa wymaga struktury `locales/{lng}/{ns}.json`. Zadbaj o czas na ręczną organizację przestrzeni nazw i mapowanie tras.
+
+</Accordion>
+<Accordion header="Wybierz Intlayer">
+
+Zależy Ci na **treściach przypisanych do komponentów**, **ścisłym TypeScript**, **błędach brakujących kluczy w czasie kompilacji**, **tree-shakingu i leniwym ładowaniu bez wysiłku**, natychmiastowej zmianie języka, synchronicznych komponentach serwerowych i wbudowanych narzędziach edycyjnych ([Edytor wizualny](https://intlayer.org/pl/doc/concept/editor), [CMS](https://intlayer.org/pl/doc/concept/cms), [tłumaczenie AI](https://intlayer.org/pl/doc/concept/auto-fill), [serwer MCP](https://intlayer.org/pl/doc/mcp-server)). Szczególnie istotne w dużych, modułowych bazach kodu i systemach projektowych.
+
+</Accordion>
+<Accordion header="Wybierz adaptery @intlayer/*-i18next">
+
+Korzystasz już z i18next i chcesz uzyskać korzyści w wielkości paczki i reaktywności bez przepisywania komponentów. Twoje pliki `locales/{lng}/{ns}.json` pozostają źródłem prawdy. Zmierzone ramię w ramię w [i18next vs @intlayer/i18next](https://intlayer.org/pl/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Dlaczego i18next jest o wiele cięższy niż inne biblioteki?">
+
+Został zaprojektowany jako środowisko uruchomieniowe niezależne od frameworka: globalna instancja, potok wtyczek, magazyn zasobów, mechanizm rozwiązywania kluczy. Ta elastyczność jest kompilowana w każdej paczce. Pusty komponent importujący jedynie bibliotekę waży **19.7 KB gzip** z `next-i18next` wobec **5.5 KB** z `next-intlayer`, a koszt ten ponoszony jest na każdej stronie, niezależnie od objętości treści.
+
+</Question>
+
+<Question title="Czy leniwe ładowanie z backendem rozwiązuje ten problem?">
+
+Rozwiązuje problem bajtów, ale nie opóźnień. Przejście na `i18next-resources-to-backend` oszczędza ~49 KB na stronę, ale dodaje zapytanie sieciowe przy zmianie języka: **123 ms** w konfiguracji `dynamic` oraz **185 ms** w `scoped-static`, w porównaniu do **3-4 ms** w Intlayer. Hydratacja wzrasta do 27.7 ms, ponieważ instancja odpytuje backend przed hydratacją Reacta.
+
+</Question>
+
+<Question title="Czy mogę osiągnąć 0% wycieku z i18next?">
+
+Tak, z konfiguracją `scoped-dynamic`: jeden namespace na trasę, backend zasobów i ręcznie utrzymywana mapa stron do przestrzeni nazw. Daje to 163.4 KB na stronę w Next.js, co nadal jest o **+22 KB** więcej niż 141.3 KB w Intlayer, który nie wymagał żadnej konfiguracji. Zobacz [optymalizację paczki](https://intlayer.org/pl/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Czy muszę przepisywać komponenty, aby przeprowadzić migrację?">
+
+Nie. `@intlayer/i18next`, `@intlayer/react-i18next` oraz `@intlayer/next-i18next` zachowują `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, formy mnogie `_one` / `_other`, sufiksy kontekstowe i `returnObjects`. Wystarczy jedna linijka wtyczki w `next.config.ts` lub `vite.config.ts`. Krok po kroku w [przewodniku migracji next-i18next](https://intlayer.org/pl/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Co dzieje się z moimi wtyczkami do i18next?">
+
+Backendy i detektory języka są akceptowane, ale pozostają bezczynne: w czasie wykonywania nie ma już nic do załadowania ani wykrycia. Detekcja języka staje się konfiguracją routingu Intlayer (prefiks URL, ciasteczko, nagłówek). Jeśli aplikacja pobiera tłumaczenia z CMS podczas żądania, użyj [Intlayer CMS](https://intlayer.org/pl/doc/concept/cms) lub poleceń `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Powiązane porównania
 
-- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer) (ten sam benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/pl/blog/lingui-vs-intlayer) (ten sam benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark) (ten sam benchmark)
+Ten sam benchmark, inne biblioteki:
+
+- [next-intl vs Intlayer](https://intlayer.org/pl/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/pl/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/pl/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/pl/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/pl/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Więcej o i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/pl/blog/i18next-vs-intlayer-i18next), porównanie adapterów na tej samej aplikacji
 - [Czy i18next jest przestarzały?](https://intlayer.org/pl/blog/is-i18next-outdated)
+- [Używanie Intlayer z i18next](https://intlayer.org/pl/blog/intlayer-with-i18next) oraz [z react-i18next](https://intlayer.org/pl/blog/intlayer-with-react-i18next)
+- [Jak zinternacjonalizować aplikację Next.js za pomocą next-i18next](https://intlayer.org/pl/blog/nextjs-internationalization-using-next-i18next)
+
+Dokumentacja referencyjna:
+
+- [Raport benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs) oraz [raport benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack)
+- Adaptery kompatybilności: [i18next](https://intlayer.org/pl/doc/compatibility/i18next), [react-i18next](https://intlayer.org/pl/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/pl/doc/compatibility/next-i18next)
+- Przewodniki migracji: [i18next](https://intlayer.org/pl/doc/migration/i18next), [react-i18next](https://intlayer.org/pl/doc/migration/react-i18next), [next-i18next](https://intlayer.org/pl/doc/migration/next-i18next)
+- [Optymalizacja paczki](https://intlayer.org/pl/doc/concept/bundle-optimization) oraz [kompilator Intlayer](https://intlayer.org/pl/doc/compiler)
+- [i18n per-komponent vs scentralizowane](https://intlayer.org/pl/blog/per-component-vs-centralized-i18n)
+- [i18n oparte na kompilatorze vs deklaratywne](https://intlayer.org/pl/blog/compiler-vs-declarative-i18n)
 
 ## Gwiazdki na GitHub
 

package/blog/pl/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Czy Intlayer jest lżejszy niż Paraglide?
+description: Paraglide wygląda na niemal bezkosztowy w benchmarkach i18n, ponieważ jego kod jest generowany bezpośrednio do Twojego repozytorium. Sprawdź, gdzie naprawdę trafia ta waga, dlaczego odczytywanie locale na każdy węzeł obciąża aplikację i jak dynamiczne ładowanie w Intlayer wysyła tylko jeden język zamiast wszystkich.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internacjonalizacja
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Czy Intlayer jest lżejszy niż Paraglide?
+
+Tak.
+
+`Paraglide` cieszy się świetną reputacją najlżejszego rozwiązania i18n na rynku, a na pierwszy rzut oka [benchmark](https://intlayer.org/pl/doc/benchmark/tanstack) zdaje się to potwierdzać: rozmiar jego biblioteki jest bliski zeru. Jednak rozmiar biblioteki równy zero wcale nie oznacza zero wysłanych bajtów. Oznacza to jedynie, że bajty znajdują się w miejscu, którego ten wskaźnik nie bada.
+
+<TOC/>
+
+## Kluczowe wnioski
+
+**Rozmiar biblioteki jest ukryty, a nie usunięty:**
+
+Paraglide generuje swój runtime i funkcje komunikatów bezpośrednio w Twojej bazie kodu. Ten kod trafia do przeglądarki, ale jest liczony jako _Twój_ kod, a nie kod biblioteki.
+
+**Brak providera to pozorny zysk:**
+
+Każde wywołanie `m.my_key()` samodzielnie rozpoznaje locale, odczytując plik cookie lub pamięć podręczną dla każdego renderowanego węzła, zamiast pobrać tę wartość raz z kontekstu.
+
+**Brak dynamicznego ładowania:**
+
+Paraglide importuje wszystkie wersje językowe komunikatu do Twojego bundle klienta. Intlayer z opcją `importMode: 'dynamic'` lub `'fetch'` ładuje wyłącznie aktualnie wyświetlane locale.
+
+**Tree shaking nie jest gwarantowany:**
+
+W niektórych z naszych benchmarków deklarowany przez Paraglide tree shaking nie przyniósł oczekiwanych rezultatów. Warto zweryfikować to we własnym bundle.
+
+## Gdzie podziewa się waga Paraglide?
+
+W raportach benchmarków metryka „rozmiar biblioteki” mierzy wielkość providera i hooków każdej biblioteki i18n w pustym komponencie, zanim dodana zostanie jakakolwiek treść.
+
+| Biblioteka (TanStack Start)   | Rozmiar lib (gz) | Rozmiar lib (min) |
+| ----------------------------- | ---------------- | ----------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB           | 4.5 KB            |
+| `react-intlayer@9.5.1`        | 5.0 KB           | 15.2 KB           |
+
+W oderwaniu od reszty aplikacji Paraglide wygrywa. Jednak Paraglide jest kompilatorem: odczytuje pliki `messages/*.json` i tworzy w Twoim repozytorium folder `paraglide/`, zawierający plik `runtime.js` (wykrywanie locale, strategie cookies i storage, lokalizacja adresów URL) oraz jedną funkcję JavaScript dla każdego komunikatu.
+
+```bash
+src/paraglide/
+├── runtime.js      # wykrywanie locale, strategie, pomocniki URL
+├── server.js
+├── messages.js     # re-eksportuje wszystkie komunikaty
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Ponieważ ten kod znajduje się w Twoim folderze `src/` i jest importowany za pomocą ścieżki względnej, bundler przypisuje go do Twojej aplikacji, a nie do pakietu w `node_modules`. W kolumnie rozmiaru biblioteki nie pojawia się niemal nic, podczas gdy dokładnie ta sama logika nadal jest dostarczana w bundle Twojej strony.
+
+Generowanie kodu samo w sobie nie jest złym pomysłem: wygenerowany runtime zawiera wyłącznie logikę wymaganą przez Twoją konfigurację (strategia prefiksów, cookie vs. local storage itp.). Intlayer osiąga ten sam cel w inny sposób: wstrzykując zmienne środowiskowe na etapie budowania, dzięki czemu bundler odrzuca gałęzie kodu, z których nie korzysta Twoja konfiguracja. Oba podejścia okazują się ostatecznie od 3 do 10 razy lżejsze niż `i18next` czy `next-intl`.
+
+Sprawiedliwe porównanie nie dotyczy zatem rozmiaru samej biblioteki. Dotyczy **kodu JavaScript faktycznie przesyłanego na stronę**.
+
+## Rzeczywista waga strony
+
+Aplikacja TanStack Start, 10 stron, pomiar na trasach `en` oraz `fr`, kompresja gzip:
+
+| Konfiguracja                       | Śr. JS strony (gz) | Ponad bazę  | Wyciek locale | Wyciek innych stron |
+| ---------------------------------- | ------------------ | ----------- | ------------- | ------------------- |
+| Baza (bez i18n)                    | 111.0 KB           | -           | 0.0%          | 0.0%                |
+| `paraglide` (dowolna strategia)    | 125.1 KB           | +14.1 KB    | 49.7%         | 0.0%                |
+| `intlayer` (`importMode: static`)  | 125.8 KB           | +14.8 KB    | 50.0%         | 0.0%                |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**       | **+7.6 KB** | **0.0%**      | **0.0%**            |
+
+Next.js 16 App Router, ta sama aplikacja:
+
+| Konfiguracja     | Śr. JS strony (gz) | Ponad bazę  |
+| ---------------- | ------------------ | ----------- |
+| Baza (bez i18n)  | 141.0 KB           | -           |
+| `paraglide-next` | 155.3 KB           | +14.3 KB    |
+| `next-intlayer`  | **141.3 KB**       | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Kompletne dane zawiera [raport benchmarku TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack) oraz [raport benchmarku Next.js](https://intlayer.org/pl/doc/benchmark/nextjs). Każdy bundle można szczegółowo przeanalizować w [repozytorium benchmarku](https://github.com/intlayer-org/benchmark-i18n).
+
+Uwagę zwracają dwa fakty:
+
+- W trybie `static` Intlayer przesyła praktycznie taką samą ilość treści jak Paraglide (125.8 KB vs 125.1 KB). Jest to w pełni zrozumiałe: oba rozwiązania dołączają wszystkie wersje językowe komunikatów używanych na stronie.
+- Paraglide pozostaje przy wadze 125.1 KB niezależnie od wybranej strategii, ponieważ nie oferuje trybu dynamicznego. Każdy wiersz w powyższej tabeli odpowiada ładowaniu statycznemu.
+
+## Brak Providera: pozorna zaleta o ukrytym koszcie
+
+Paraglide nie wymaga providera. Importujesz komunikat i wywołujesz go:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Brak kontekstu, brak komponentu otaczającego, brak hooka. Wydaje się to prostsze. Jednak informacja o wybranym języku i tak musi skądś pochodzić. Każda wygenerowana funkcja komunikatu wygląda mniej więcej tak (postać uproszczona):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // rozwiązywane przy każdym wywołaniu
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...po jednej gałęzi na każdy język
+};
+```
+
+Funkcja `getLocale()` sprawdza po kolei skonfigurowane strategie (cookie, local storage, URL, domyślne locale), aby ustalić bieżący język. Oznacza to, że każdy renderowany węzeł tekstowy (`<>{m.my_key()}</>`) uruchamia własny proces rozpoznawania locale, co obejmuje odczyt `document.cookie` w przeglądarce. Strona z 200 przetłumaczonymi ciągami znaków wykonuje tę operację 200 razy podczas jednego renderowania, a następnie powtarza to przy każdym ponownym renderowaniu.
+
+Biblioteka oparta na providerze odczytuje locale **dokładnie raz**, zapisuje je w kontekście (albo w sygnale czy store), a każdy węzeł pobiera wartość gotową już w pamięci. Provider kosztuje zaledwie kilkaset bajtów. Rezygnacja z niego kosztuje cykle procesora przy każdym renderze, co wyraźnie widać w wynikach benchmarku: czasy ładowania strony i przełączania języków w Paraglide na TanStack Start wyraźnie ustępują Intlayerowi (22.1 ms vs 14.6 ms przy ładowaniu strony, 4.3 ms vs 3.2 ms w reaktywności E2E).
+
+## Doświadczenie programisty (DX)
+
+Źródłem prawdy w Paraglide jest format JSON, ale programista nigdy nie importuje plików JSON bezpośrednio. Importuje wygenerowany plik `.js`:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/pl.json"
+{
+  "hero_title": "Publikuj swoją aplikację w każdym języku"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Dostępne dopiero po ponownym wygenerowaniu przez kompilator z pliku JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      pl: "Publikuj swoją aplikację w każdym języku",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Taki cykl pracy wiąże się z niedogodnościami:
+
+- Każda zmiana w pliku JSON wymaga ponownej generacji, zanim import zostanie rozpoznany lub zaktualizują się typy.
+- Wygenerowany folder `paraglide/` musi być zatwierdzany w gicie (co prowadzi do konfliktów scalania w wygenerowanych plikach przy każdym PR zmieniającym teksty) albo ignorowany (co wymaga kroku generowania przed każdym sprawdzaniem typów, testem i zadaniem CI).
+- Każdy ciąg znaków staje się wywołaniem funkcji. Stałe zamieniają się w `m.key()` w całym kodzie, nawet tam, gdzie w zupełności wystarczyłaby zwykła wartość tekstowa.
+
+## Tree Shaking: sprawdź swój bundle
+
+Główną zaletą promowaną przez Paraglide jest to, że nieużywane komunikaty są usuwane przez tree shaking, ponieważ każdy komunikat stanowi niezależny eksport. W benchmarku Svelte + Vite rozwiązanie to działa zgodnie z zapowiedziami.
+
+W innych środowiskach tak się jednak nie stało. W naszych testach [Next.js](https://intlayer.org/pl/doc/benchmark/nextjs) strony Paraglide ważyły o 14 KB więcej niż aplikacja bazowa, podczas gdy `next-intlayer` dodał zaledwie 0.3 KB. Wcześniejsze pomiary na TanStack Start wykazały także, że komunikaty z innych podstron trafiały do bundle bieżącej trasy.
+
+Skuteczność tree shakingu zależy od używanego bundlera (Turbopack, Rolldown, Rollup), sposobu importowania komunikatów (`import { m }` vs `import * as m`) oraz analizy efektów ubocznych. Wybierając Paraglide ze względu na rozmiar, warto otworzyć wizualizator bundle i sprawdzić, jak zachowuje się on w Twojej aplikacji.
+
+## Brak dynamicznego ładowania
+
+Oto fundamentalne ograniczenie architektoniczne. Paraglide nie udostępnia mechanizmu ładowania jednego języka na raz: każda funkcja komunikatu statycznie importuje implementację każdego języka, co sprawia, że wszystkie wersje językowe trafiają do bundle klienta.
+
+Przy 2 językach marnuje się połowa przesyłanych danych tłumaczeń, co odpowiada zmierzonemu wyżej ~50% wyciekowi locale. Przy 10 językach marnuje się 90% danych. Przy 30 językach aż 97%.
+
+Przejście na dynamiczne ładowanie również nie rozwiązałoby problemu: przy jednej funkcji na każdy komunikat leniwe ładowanie każdej z nich generowałoby tysiące zapytań sieciowych.
+
+Intlayer pozwala na elastyczny wybór, globalnie lub na poziomie słownika:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Co jest przesyłane do klienta                          | W porównaniu z Paraglide           |
+| ------------ | ------------------------------------------------------ | ---------------------------------- |
+| `static`     | Wszystkie języki słowników używanych na stronie        | Teoretycznie identyczna wielkość   |
+| `dynamic`    | Tylko bieżące locale, ładowane na żądanie dla słownika | **N razy lżejsze** przy N językach |
+| `fetch`      | Tylko bieżące locale, pobierane przez Live Sync API    | **N razy lżejsze** przy N językach |
+
+Dzięki [transformacji w trakcie budowy](https://intlayer.org/pl/doc/concept/bundle-optimization) oraz trybowi `importMode: 'static'`, Intlayer ładuje w teorii dokładnie tę samą zawartość co Paraglide. Z kolei przy `'dynamic'` lub `'fetch'` ładuje tylko to, czego potrzebuje aktualny język: w aplikacji obsługującej N języków rozmiar danych tłumaczeń jest N razy mniejszy niż w Paraglide.
+
+## Kiedy Paraglide nadal ma sens?
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite z niewielką liczbą języków">
+
+Jeśli Twoim stosem technologicznym jest Svelte z Vite i obsługujesz dwa lub trzy języki, tree shaking działa zgodnie z oczekiwaniami, a narzut dodatkowych języków pozostaje niewielki.
+
+</Accordion>
+<Accordion header="Istniejący przepływ pracy oparty na inlang">
+
+Jeśli Twój zespół aktywnie korzysta z ekosystemu inlang (Fink, Sherlock, wtyczki formatów komunikatów), Paraglide integruje się z nim natywnie.
+
+</Accordion>
+</AccordionGroup>
+
+## Przetestuj na własnej aplikacji
+
+Sprawdź wagę transferu i wycieki locale w swojej działającej aplikacji za pomocą bezpłatnego narzędzia [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Aby skonfigurować Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Przydatne materiały
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/pl/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/pl/doc/benchmark/nextjs)
+- [Optymalizacja bundle i `importMode`](https://intlayer.org/pl/doc/concept/bundle-optimization)
+- [Jak wybrać bibliotekę i18n dla React](https://intlayer.org/pl/blog/how-to-pick-react-i18n-library)
+- [Zalety i wady internacjonalizacji opartej na kompilatorze](https://intlayer.org/pl/blog/compiler-vs-declarative-i18n)