@intlayer/docs 9.5.6 → 9.5.8

package/blog/it/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 e confronto 2026"
 description: "react-i18next e next-i18next misurati rispetto a Intlayer su Next.js e TanStack Start. Dimensioni del bundle, dispersione dei contenuti, reattività al cambio lingua ed esperienza di sviluppo."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark di internazionalizzazione (i18n) per React e Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` è il framework di i18n più diffuso nell'ecosistema JavaScript. Attraverso `react-i18next` e `next-i18next`, alimenta un'ampia quota di applicazioni React e Next.js. Intlayer è un'alternativa basata su compilatore e con ambito per componente.
 
 Questo articolo li mette a confronto attraverso misurazioni concrete anziché elenchi di funzionalità. I dati provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open source che compila la stessa applicazione con ciascuna libreria e registra ciò che il browser scarica effettivamente.
@@ -99,6 +101,10 @@ Per ciascuna build, la suite registra:
 
 ### Risultati su Next.js (`next-i18next`)
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Libreria                          | Strategia      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | Reattività E2E | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (senza i18n)             | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Per ciascuna build, la suite registra:
 - **Dimensioni dei componenti.** Un componente con `useTranslation()` compila tra i 26 e i 79 KB; lo stesso componente con `useIntlayer()` si attesta a 6.9 KB.
 - **L'idratazione** sale a 27.7 ms nella configurazione `dynamic`: l'istanza i18next si inizializza e risolve il proprio backend sul client prima che React possa idratare la pagina.
 
+<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;"
+/>
+
+> Tabella completa, ogni libreria e ogni strategia, nel [rapporto di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs).
+
 ### Risultati su TanStack Start (`react-i18next`)
 
 Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isolando la comparazione dalle specificità di Next.js.
@@ -141,8 +156,19 @@ Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isoland
 - La riga `static` di Intlayer ha già **0% di dispersione di pagina** poiché vengono inclusi solo i dizionari importati dai componenti effettivi della pagina. Abilitando `importMode: 'dynamic'` si azzera anche la dispersione linguistica.
 - **Dimensioni componenti**: 24-27 KB con `react-i18next` contro 6-8 KB con Intlayer. `useTranslation()` vincola ogni componente all'istanza globale di 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;"
+/>
+
+> Tabella completa nel [rapporto di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack).
+
 ## Origine del divario: Istanza globale vs dizionari compilati
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` è nato nel 2012 come runtime: un'istanza globale mantiene un archivio di risorse, i plugin la espandono e `t()` ricerca le chiavi a runtime. Tale architettura garantisce grande versatilità (qualsiasi framework, backend e formato), ma introduce inevitabilmente overhead:
 
 ```bash
@@ -166,7 +192,13 @@ Stessa applicazione di prova su TanStack Start con `react-i18next` puro, isoland
                 └── page.tsx     # deve sapere che necessita di ["common", "about"]
 ```
 
-L'istanza non può anticipare le chiavi richieste da un componente. Ottimizzare significa che **tu** devi suddividere i file in namespace, **tu** devi elencare i namespace richiesti da ogni pagina e **tu** devi mantenere allineata la lista quando i componenti vengono spostati. Come riportato nelle [note del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantenere la sicurezza dei tipi e sapere esattamente quale namespace includere su quale pagina è un incubo".
+L'istanza non può anticipare le chiavi richieste da un componente. Ottimizzare significa che **tu** devi suddividere i file in namespace, **tu** devi elencare i namespace richiesti da ogni pagina e **tu** devi mantenere allineata la lista quando i componenti vengono spostati.
+
+La spesa cresce su due assi contemporaneamente, pagine e lingue:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Come riportato nelle [note del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantenere la sicurezza dei tipi e sapere esattamente quale namespace includere su quale pagina è un incubo".
 
 Intlayer elimina l'istanza globale. I contenuti sono dichiarati accanto al componente e il compilatore risolve il grafico delle dipendenze durante il build:
 
@@ -193,7 +225,8 @@ Intlayer elimina l'istanza globale. I contenuti sono dichiarati accanto al compo
 
 ### Configurazione
 
-**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 (
 
 A questo si aggiunge un `I18nProvider` client che reinizializza l'istanza con le medesime opzioni, `generateStaticParams` e un elenco `namespaces` per ciascuna pagina.
 
-**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>
+
 ### Componente client
 
-**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 = () => {
 
 > La pagina che renderizza questo componente deve caricare il namespace `about`, e `t("counter.label")` rimane una stringa semplice finché non si estende `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 = () => {
 
 `label` e `increment` sono tipizzati rigorosamente: ogni errore di battitura genera un errore TypeScript e una traduzione mancante blocca la compilazione.
 
+</Tab>
+</Tabs>
+
 ### Componente server sincrono
 
-**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) => (
 
 La pagina invoca `i18n.getFixedT(locale, "about")` e trasmette `t` e `locale` verso il basso tramite 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>
+
 ## Conserva l'API di i18next, sfrutta le prestazioni di Intlayer
 
 Non serve riscrivere i componenti per beneficiare dei numeri del benchmark. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` sono adattatori compatibili pronti all'uso: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurali `_one` / `_other`, suffissi di contesto e `returnObjects` continuano a funzionare, erogati tramite i dizionari compilati da Intlayer.
@@ -415,18 +462,85 @@ Consulta le guide di migrazione: [i18next](https://intlayer.org/it/doc/migration
 
 ## Quando scegliere quale soluzione?
 
-- **Scegli i18next** se necessiti del suo ecosistema di plugin (rilevatori, backend, ICU, Locize), se gestisci la localizzazione anche fuori da React (servizi Node, vanilla JS, altri framework), se il tuo team ha già consolidata esperienza o se una piattaforma di traduzione richiede `locales/{lng}/{ns}.json`. Considera il tempo necessario per organizzare i namespace, configurare un backend e mantenere aggiornata la mappa delle route se le performance sono critiche.
-- **Scegli Intlayer** se desideri **contenuti integrati a livello di componente**, **TypeScript rigoroso**, **errori in fase di build per chiavi mancanti**, **tree-shaking e lazy loading a costo zero**, cambio lingua istantaneo, componenti server sincroni e strumenti editoriali integrati (editor visuale, CMS, traduzione con IA, server MCP). Ideale per codebase modulari e design system.
-- **Scegli gli adattatori `@intlayer/*-i18next`** se utilizzi già i18next e vuoi ottenere vantaggi immediati su bundle e reattività senza riscrivere i componenti.
+<AccordionGroup>
+<Accordion header="Scegliere i18next">
+
+Se necessiti del suo ecosistema di plugin (rilevatori, backend, ICU, Locize), se gestisci la localizzazione anche fuori da React (servizi Node, vanilla JS, altri framework), se il tuo team ha già consolidata esperienza o se una piattaforma di traduzione richiede `locales/{lng}/{ns}.json`. Considera il tempo necessario per organizzare i namespace, configurare un backend e mantenere aggiornata la mappa delle route se le performance sono critiche.
+
+</Accordion>
+<Accordion header="Scegliere Intlayer">
+
+Desideri **contenuti limitati ai componenti**, **TypeScript rigoroso**, **errori di chiavi mancanti in fase di compilazione**, **tree-shaking e lazy loading senza sforzo**, cambio istantaneo della lingua, componenti server sincroni e strumenti editoriali integrati ([Visual Editor](https://intlayer.org/it/doc/concept/editor), [CMS](https://intlayer.org/it/doc/concept/cms), [traduzione AI](https://intlayer.org/it/doc/concept/auto-fill), [server MCP](https://intlayer.org/it/doc/mcp-server)). Particolarmente rilevante per basi di codice modulari e sistemi di design.
+
+</Accordion>
+<Accordion header="Scegliere gli adattatori @intlayer/*-i18next">
+
+Utilizzi già i18next e desideri i vantaggi del bundle e della reattività senza riscrivere i componenti. I tuoi file `locales/{lng}/{ns}.json` rimangono l'unica fonte di verità. Misurato fianco a fianco in [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Perché i18next è molto più pesante delle altre librerie?">
+
+È stato progettato come runtime agnostico rispetto al framework: un'istanza globale, una pipeline di plugin, un archivio di risorse, un risolutore di chiavi. Questa flessibilità viene compilata in ogni bundle. Un componente vuoto che importa solo la libreria costa **19.7 KB gzip** con `next-i18next` contro **5.5 KB** con `next-intlayer`, e questo costo viene pagato su ogni pagina, qualunque sia il peso dei tuoi contenuti.
+
+</Question>
+
+<Question title="Il caricamento lazy con un backend risolve il problema?">
+
+Risolve i byte, non la latenza. Il passaggio a `i18next-resources-to-backend` consente di risparmiare ~49 KB per pagina, ma aggiunge un round-trip di rete al cambio di lingua: **123 ms** nella configurazione `dynamic` e **185 ms** in `scoped-static`, contro **3-4 ms** con Intlayer. Anche l'idratazione sale a 27.7 ms perché l'istanza risolve il suo backend prima che React possa idratare.
+
+</Question>
+
+<Question title="Posso raggiungere lo 0% di leakage con i18next?">
+
+Sì, con `scoped-dynamic`: un namespace per route, un backend di risorse e una mappa pagina-namespace gestita a mano. Arriva a 163.4 KB per pagina su Next.js, comunque **+22 KB** rispetto ai 141.3 KB di Intlayer, che non ha richiesto alcuna configurazione. Consulta l'[ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Devo riscrivere i miei componenti per migrare?">
+
+No. `@intlayer/i18next`, `@intlayer/react-i18next` e `@intlayer/next-i18next` mantengono `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurali `_one` / `_other`, suffissi di contesto e `returnObjects`. Una sola riga di plugin in `next.config.ts` o `vite.config.ts`. Passo dopo passo nella [guida alla migrazione di next-i18next](https://intlayer.org/it/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Cosa succede ai miei plugin di i18next?">
+
+I backend e i rilevatori di lingua sono accettati ma inerti: non c'è più nulla da caricare o rilevare a runtime. Il rilevamento della lingua diventa la configurazione di routing di Intlayer (prefisso URL, cookie, header). Se la tua app recupera traduzioni da un CMS al momento della richiesta, usa invece il [CMS di Intlayer](https://intlayer.org/it/doc/concept/cms) o `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer) (stesso benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/it/blog/lingui-vs-intlayer) (stesso benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark) (stesso benchmark)
+Stesso benchmark, altre librerie:
+
+- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/it/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/it/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/it/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Approfondire su i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next), gli adattatori misurati sulla stessa applicazione
 - [i18next è superato?](https://intlayer.org/it/blog/is-i18next-outdated)
+- [Utilizzare Intlayer con i18next](https://intlayer.org/it/blog/intlayer-with-i18next) e [con react-i18next](https://intlayer.org/it/blog/intlayer-with-react-i18next)
+- [Come internazionalizzare un'app Next.js con next-i18next](https://intlayer.org/it/blog/nextjs-internationalization-using-next-i18next)
+
+Documenti di riferimento:
+
+- [Rapporto di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs) e [rapporto di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- Adattatori di compatibilità: [i18next](https://intlayer.org/it/doc/compatibility/i18next), [react-i18next](https://intlayer.org/it/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/it/doc/compatibility/next-i18next)
+- Guide alla migrazione: [i18next](https://intlayer.org/it/doc/migration/i18next), [react-i18next](https://intlayer.org/it/doc/migration/react-i18next), [next-i18next](https://intlayer.org/it/doc/migration/next-i18next)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
+- [i18n per componente vs centralizzata](https://intlayer.org/it/blog/per-component-vs-centralized-i18n)
+- [i18n guidata da compilatore vs dichiarativa](https://intlayer.org/it/blog/compiler-vs-declarative-i18n)
 
 ## Stelle su GitHub
 

package/blog/it/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer è più leggero di Paraglide?
+description: Paraglide sembra quasi gratuito nei benchmark i18n perché il suo codice viene generato nel tuo repository. Ecco dove finisce realmente quel peso, perché la risoluzione della locale per nodo costa e come il caricamento dinamico di Intlayer invia una sola lingua anziché tutte.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internazionalizzazione
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer è più leggero di Paraglide?
+
+Sì.
+
+`Paraglide` ha la reputazione di essere la soluzione i18n più leggera in circolazione, e a prima vista il [benchmark](https://intlayer.org/it/doc/benchmark/tanstack) sembra confermarlo: la dimensione della sua libreria è vicina allo zero. Tuttavia, una dimensione della libreria pari a zero non significa zero byte inviati. Significa solo che i byte si trovano dove la metrica non va a guardare.
+
+<TOC/>
+
+## Punti chiave
+
+**La dimensione della libreria è nascosta, non eliminata:**
+
+Paraglide genera il suo runtime e le funzioni dei messaggi direttamente nella tua codebase. Quel codice viene inviato al browser, ma viene conteggiato come _tuo_ codice, non come codice della libreria.
+
+**Nessun provider non significa un vantaggio gratuito:**
+
+Ogni chiamata a `m.my_key()` risolve la locale in autonomia, leggendo il cookie o lo storage per ciascun nodo renderizzato, invece di leggerlo una sola volta da un contesto.
+
+**Nessun caricamento dinamico:**
+
+Paraglide importa ogni locale di un messaggio nel bundle client. Intlayer con `importMode: 'dynamic'` o `'fetch'` carica solo la lingua effettivamente renderizzata.
+
+**Il tree shaking non è garantito:**
+
+In alcuni dei nostri benchmark, il tree shaking promesso da Paraglide non ha avuto effetto. Verifica il tuo stesso bundle.
+
+## Dove finisce il peso di Paraglide?
+
+Nei report di benchmark, la metrica "dimensione della libreria" misura il provider e gli hook di ciascuna libreria i18n in un componente vuoto, prima che venga aggiunto qualsiasi contenuto.
+
+| Libreria (TanStack Start)     | Dimensione lib (gz) | Dimensione 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              |
+
+Letto in isolamento, Paraglide vince. Ma Paraglide è un compilatore: legge i tuoi file `messages/*.json` e scrive una cartella `paraglide/` nel tuo repository, contenente un file `runtime.js` (rilevamento della locale, strategie per cookie e storage, localizzazione degli URL) e una funzione JavaScript per ciascun messaggio.
+
+```bash
+src/paraglide/
+├── runtime.js      # rilevamento locale, strategie, helper per URL
+├── server.js
+├── messages.js     # riesporta ogni messaggio
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Poiché questo codice si trova nella tua cartella `src/` e lo importi con un percorso relativo, il bundler lo attribuisce alla tua applicazione e non a un pacchetto in `node_modules`. La colonna della dimensione della libreria mostra quasi nulla, mentre la stessa logica viene comunque inclusa nel bundle della tua pagina.
+
+Generare codice non è un'idea sbagliata in sé: il runtime generato include solo la logica richiesta dalla tua configurazione (strategia di prefisso, cookie vs. local storage, ecc.). Intlayer ottiene lo stesso risultato in modo diverso, iniettando variabili d'ambiente in fase di build in modo che il bundler elimini i rami che la tua configurazione non utilizza. Entrambi gli approcci risultano da 3 a 10 volte più leggeri rispetto a `i18next` o `next-intl`.
+
+Il confronto equo non riguarda quindi la dimensione della libreria. Riguarda **il JavaScript effettivamente inviato per pagina**.
+
+## Peso per pagina, misurato
+
+Applicazione TanStack Start, 10 pagine, misurata sulle route `en` e `fr`, compressa con gzip:
+
+| Configurazione                     | Media JS pag (gz) | Sopra la base | Perdita di locale | Perdita altre pagine |
+| ---------------------------------- | ----------------- | ------------- | ----------------- | -------------------- |
+| Base (senza i18n)                  | 111.0 KB          | -             | 0.0%              | 0.0%                 |
+| `paraglide` (qualsiasi 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, stessa applicazione:
+
+| Configurazione    | Media JS pag (gz) | Sopra la base |
+| ----------------- | ----------------- | ------------- |
+| Base (senza i18n) | 141.0 KB          | -             |
+| `paraglide-next`  | 155.3 KB          | +14.3 KB      |
+| `next-intlayer`   | **141.3 KB**      | **+0.3 KB**   |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Dati completi nel [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack) e nel [report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs). Ogni bundle può essere ispezionato nel [repository del benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Due aspetti emergono con evidenza:
+
+- In modalità `static`, Intlayer invia praticamente lo stesso contenuto di Paraglide (125.8 KB contro 125.1 KB). È quanto ci si aspetta: entrambi includono tutte le lingue dei messaggi utilizzati da una pagina.
+- Paraglide rimane a 125.1 KB con qualsiasi strategia, poiché è privo di una modalità dinamica. Ogni riga nella tabella precedente corrisponde alla variante statica.
+
+## Nessun Provider: un'idea all'apparenza ottima che non lo è
+
+Paraglide non necessita di provider. Si importa un messaggio e lo si invoca:
+
+```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>
+);
+```
+
+Nessun contesto, nessun wrapper, nessun hook. Sembra più semplice. Ma la locale deve pur essere ricavata da qualche parte. Ogni funzione di messaggio generata assomiglia grossomodo a questo (versione semplificata):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // risolto a ogni invocazione
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...un ramo per ogni locale
+};
+```
+
+E `getLocale()` scansiona le strategie configurate (cookie, local storage, URL, locale di base) per trovare la locale attiva. Pertanto, ogni nodo di testo renderizzato (`<>{m.my_key()}</>`) esegue la propria risoluzione della lingua, inclusa la lettura di `document.cookie` nel browser. Una pagina con 200 stringhe tradotte risolve la locale 200 volte per render, e di nuovo a ogni re-render.
+
+Una libreria basata su provider legge la lingua **una sola volta**, la memorizza in un contesto (o in un segnale, o in uno store), e ogni nodo legge un valore già presente in memoria. Il provider costa poche centinaia di byte. Eliminarlo consuma cicli di CPU a ogni render, come dimostrato nel benchmark: i tempi di caricamento pagina e di cambio lingua di Paraglide sono costantemente inferiori rispetto a quelli di Intlayer su TanStack Start (22.1 ms contro 14.6 ms nel caricamento pagina, 4.3 ms contro 3.2 ms nella reattività E2E).
+
+## Esperienza di sviluppo (DX)
+
+La fonte di verità di Paraglide è il formato JSON, ma non si importa mai il file JSON direttamente. Si importa il file `.js` generato:
+
+<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/it.json"
+{
+  "hero_title": "Pubblica la tua app in ogni lingua"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Esiste solo dopo che il compilatore lo ha rigenerato a partire dal 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({
+      it: "Pubblica la tua app in ogni lingua",
+      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>
+
+Questo ciclo di lavoro comporta dei compromessi:
+
+- Ogni modifica a un file JSON richiede una rigenerazione prima che l'importazione si risolva o che i tipi vengano aggiornati.
+- La cartella generata `paraglide/` deve essere inclusa nel repository (generando conflitti di merge sui file generati in ogni PR che modifica testi) oppure ignorata (richiedendo un passaggio di generazione prima di ogni type check, test e job di CI).
+- Ogni stringa diventa una chiamata a funzione. Le costanti diventano ovunque `m.key()`, anche nei punti in cui basterebbe un valore statico.
+
+## Tree Shaking: verifica il tuo bundle
+
+La promessa fondamentale di Paraglide è che i messaggi non utilizzati vengono eliminati tramite tree shaking, poiché ogni messaggio rappresenta un export separato. Nel benchmark Svelte + Vite, questo funziona come pubblicizzato.
+
+In altri contesti, non è stato così. Nel nostro test su [Next.js](https://intlayer.org/it/doc/benchmark/nextjs), le pagine di Paraglide pesano 14 KB in più rispetto all'applicazione di base, mentre `next-intlayer` aggiunge solo 0.3 KB. Test precedenti su TanStack Start hanno mostrato che anche i messaggi di altre pagine finivano nel bundle della route.
+
+Il tree shaking dipende dal tuo bundler (Turbopack, Rolldown, Rollup), da come vengono importati i messaggi (`import { m }` vs. `import * as m`) e dall'analisi dei side effect. Se scegli Paraglide per le sue dimensioni ridotte, apri il visualizzatore del bundle e controlla che tali promesse si mantengano nella tua applicazione.
+
+## Nessun caricamento dinamico
+
+Questo è il limite strutturale. Paraglide non prevede un meccanismo per caricare una sola lingua alla volta: ogni funzione di messaggio importa staticamente l'implementazione di ciascuna lingua, cosicché tutte le lingue finiscono nel bundle inviato al client.
+
+Con 2 lingue, metà del payload delle traduzioni viene sprecato, in linea con il ~50% di perdita di locale misurato in precedenza. Con 10 lingue, il 90%. Con 30 lingue, il 97%.
+
+Passare al caricamento dinamico non risolverebbe il problema: disponendo di una funzione per ciascun messaggio, caricare ogni funzione in modalità lazy comporterebbe migliaia di richieste di rete.
+
+Intlayer consente di scegliere la strategia, a livello globale o per dizionario:
+
+```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` | Cosa viene inviato al client                               | vs. Paraglide                        |
+| ------------ | ---------------------------------------------------------- | ------------------------------------ |
+| `static`     | Tutte le lingue dei dizionari utilizzati dalla pagina      | Teoricamente lo stesso contenuto     |
+| `dynamic`    | Solo la lingua attiva, caricata on demand per dizionario   | **N volte più leggero** con N lingue |
+| `fetch`      | Solo la lingua attiva, recuperata tramite la Live Sync API | **N volte più leggero** con N lingue |
+
+Grazie alla [trasformazione in fase di build](https://intlayer.org/it/doc/concept/bundle-optimization) e alla modalità `importMode: 'static'`, Intlayer carica, in teoria, esattamente lo stesso contenuto di Paraglide. Con `'dynamic'` o `'fetch'`, carica solo ciò che la lingua corrente richiede: per un'applicazione in N lingue, il payload delle traduzioni è N volte inferiore rispetto a Paraglide.
+
+## Quando Paraglide è ancora adatto
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite con poche lingue">
+
+Se il tuo stack è Svelte con Vite e supporti due o tre lingue, il tree shaking funziona come promesso e il sovraccarico delle lingue rimane minimo.
+
+</Accordion>
+<Accordion header="Workflow inlang esistente">
+
+Se il tuo team utilizza già l'ecosistema inlang (Fink, Sherlock, plugin per i formati dei messaggi), Paraglide vi si integra in modo nativo.
+
+</Accordion>
+</AccordionGroup>
+
+## Provalo sulla tua applicazione
+
+Verifica il payload e le perdite di locale della tua applicazione in produzione con l'[i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuito:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Per configurare 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
+```
+
+## Ulteriori letture
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/it/doc/benchmark/nextjs)
+- [Ottimizzazione del bundle e `importMode`](https://intlayer.org/it/doc/concept/bundle-optimization)
+- [Come scegliere una libreria i18n per React](https://intlayer.org/it/blog/how-to-pick-react-i18n-library)
+- [Perché scegliere l'internazionalizzazione guidata da compilatore](https://intlayer.org/it/blog/compiler-vs-declarative-i18n)