@intlayer/docs 9.5.5 → 9.5.7

package/blog/it/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: Stessa API, Bundle Diverso"
 description: Cosa cambia quando le importazioni di next-intl di un'app Next.js vengono servite dall'adapter di compatibilità @intlayer/next-intl. Dimensione del bundle, perdite, dimensione dei componenti e idratazione misurate sullo stesso codice, più cosa mantiene, ignora e non può sostituire l'adapter.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | Stessa API, Bundle Diverso
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` è un compat adapter: espone l'API di `next-intl` (`useTranslations`, `getTranslations`, `useLocale`, `t.rich()`, ICU plurals, `NextIntlClientProvider`...) e la serve da dizionari compilati da Intlayer. Il codice dell'applicazione non cambia. Il bundle sì.
 
 Questo articolo confronta i due sulla stessa applicazione Next.js, costruita una volta con `next-intl` e una volta con l'adapter. I numeri provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open-source che registra ciò che il browser effettivamente scarica. Se vuoi il confronto `next-intl` vs Intlayer come librerie, leggi [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). Questo riguarda ciò che l'adapter cambia quando mantieni i tuoi componenti come sono.
@@ -109,6 +111,10 @@ Per ogni build, la suite registra:
 
 ### Risultati su Next.js
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -129,6 +135,15 @@ Per ogni build, la suite registra:
 - **L'idratazione è 2 ms più veloce** (12.8 vs 14.7 ms): non c'è nessun oggetto messaggio da deserializzare dal payload RSC prima che React possa idrare.
 - **L'adapter non è il runtime nativo.** `next-intlayer` si posiziona a **141.3 KB**, +0.3 KB sopra l'app base, con un runtime di 5.5 KB. L'adapter trasporta la superficie API di `next-intl` (`useFormatter`, `t.rich`, il risolutore ICU) in cima al core di Intlayer, da cui 8.0 KB e +6 KB per pagina. È il ponte, non la destinazione.
 
+<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 [report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs).
+
 ### Risultati su TanStack Start (`use-intl`)
 
 `use-intl` è il core framework-agnostico di `next-intl`. Il suo adapter, `@intlayer/use-intl`, segue lo stesso design con un plugin Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ Per ogni build, la suite registra:
 - **Lo switching delle locale è più veloce.** Gli setup `use-intl` ottimizzati impiegano **13-21 ms** per aggiornare `html[lang]`; l'adapter impiega **4-9 ms**. Meno componenti vengono renderizzati di nuovo, e niente viene ripreso da un albero di messaggi.
 - **`static` mantiene ogni locale.** La riga `static` dell'adapter mostra una perdita di locale del 49,7%, la stessa di Intlayer nativo in modalità `static`: tutte le locale vengono raggruppate, solo i dizionari della pagina. Una riga di configurazione (`importMode: 'dynamic'`) la rimuove.
 
+<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 [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack).
+
 ## Perché i numeri cambiano
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Poiché niente nel componente è cambiato, i guadagni provengono interamente da ciò a cui `useTranslations` è associato.
 
-**Con `next-intl`**, il binding è il provider. `NextIntlClientProvider` riceve l'intero oggetto `messages` per la locale; ogni `useTranslations("about")` legge da esso. Il bundler vede un componente che importa un hook che legge un context, e non può sapere che solo il ramo `about` è utilizzato. Le route di seguito condividono tutti lo stesso oggetto message, quindi la colonna page-leak legge ~90% fino a quando non dividi il file tu stesso.
+**Con `next-intl`**, il binding è il provider. `NextIntlClientProvider` riceve l'intero oggetto `messages` per la locale; ogni `useTranslations("about")` legge da esso. Il bundler vede un componente che importa un hook che legge un context, e non può sapere che solo il ramo `about` è utilizzato. Le route di seguito condividono tutti lo stesso oggetto message, quindi la colonna page-leak legge ~90% fino a quando non dividi il file tu stesso, e lo spreco cresce su due assi contemporaneamente, pagine e impostazioni locali:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## Limiti da conoscere prima di iniziare
 
-- **La configurazione del routing si sposta in `intlayer.config.ts`.** `createNavigation(routing)` e `createMiddleware(routing)` mantengono la loro firma ma ignorano l'argomento: le locale, la locale predefinita e la strategia di prefisso provengono dalla configurazione `routing` di Intlayer. Se utilizzi i `pathnames` localizzati di `next-intl` (`/about` → `/a-propos`), l'adapter non li interpola; `routing.rewrite` di Intlayer copre quel caso ma è una modifica separata.
-- **`useTranslations()` senza namespace non è vincolato.** Il pass di ottimizzazione ha bisogno di uno spazio dei nomi statico per sapere quale dizionario importare. Una chiamata nuda funziona ancora, attraverso un registro di runtime che fa riferimento a ogni dizionario, che è esattamente la perdita che stavi cercando di rimuovere. Passa il namespace.
-- **L'adapter non è gratuito.** 8.0 KB di runtime rispetto a 5.5 KB per `next-intlayer`, e +6-7 KB per pagina rispetto alla build nativa. Questo copre la superficie API di `next-intl`. Se raggiungi il punto in cui ogni componente è stato spostato a `useIntlayer`, elimina l'adapter.
-- **`messages`, `timeZone`, `now` sul provider vengono ignorati.** I formatter sono supportati da `Intl` nativo e solo la locale ne influenza l'output; se dipendi da un fuso orario forzato o da un `now` fisso per date stabili durante l'hydration, gestiscilo nel sito di chiamata.
+<AccordionGroup>
+<Accordion header="La configurazione di routing si sposta in intlayer.config.ts">
+
+`createNavigation(routing)` e `createMiddleware(routing)` mantengono la loro firma ma ignorano l'argomento: lingue, lingua predefinita e strategia di prefisso provengono dalla configurazione `routing` di Intlayer. Se usi i `pathnames` localizzati di `next-intl` (`/about` in `/a-propos`), l'adattatore non li interpola; `routing.rewrite` di Intlayer copre quel caso ma è una modifica separata.
+
+</Accordion>
+<Accordion header="useTranslations() senza namespace non è associato">
+
+Il passaggio di ottimizzazione ha bisogno di un namespace statico per sapere quale dizionario importare. Una chiamata senza namespace funziona comunque, tramite un registro di runtime che fa riferimento a ciascun dizionario, il che corrisponde esattamente alla dispersione che stavi cercando di rimuovere. Passa il namespace.
+
+</Accordion>
+<Accordion header="L'adattatore non è gratuito">
+
+8.0 KB di runtime contro 5.5 KB per `next-intlayer` e +6-7 KB per pagina rispetto alla build nativa. Paga per la superficie API di `next-intl`. Se arrivi al punto in cui ogni componente è passato a `useIntlayer`, rimuovi l'adattatore.
+
+</Accordion>
+<Accordion header="messages, timeZone e now sul provider vengono ignorati">
+
+I formattatori sono supportati dall'API nativa `Intl` e solo la lingua influenza il loro output. Se ti affidi a un fuso orario forzato o a un `now` fisso per date stabili all'idratazione, gestiscilo nel punto di chiamata. Vedi [formattazione di date, orari e numeri](https://intlayer.org/it/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## Quando usare quale?
 
-- **Rimani su `next-intl`** se la tua app è piccola, il tuo bundle non è una preoccupazione, e il tuo team è a suo agio nel gestire i namespace e `pick()` per pagina.
-- **Usa `@intlayer/next-intl`** se sei attualmente su `next-intl` e desideri i vantaggi di bundle, leakage e hydration, chiavi tipizzate e gli strumenti CLI / CMS senza una riscrittura. Questo è il punto di ingresso consigliato per qualsiasi codebase `next-intl` esistente.
-- **Vai nativo (`next-intlayer`)** per i nuovi progetti, o una volta che l'adapter ha svolto il suo lavoro. È il più leggero dei tre (5.5 KB, +0.3 KB per pagina) e sblocca i server component sincroni, i file `.content.ts` per componente e l'intero set di funzionalità.
+<AccordionGroup>
+<Accordion header="Rimani su next-intl">
+
+La tua app è piccola, il bundle non è un problema e il tuo team gestisce comodamente namespace e `pick()` per pagina.
+
+</Accordion>
+<Accordion header="Usa @intlayer/next-intl">
+
+Usi già `next-intl` oggi e desideri i vantaggi di bundle, dispersione e idratazione, chiavi tipizzate e strumenti CLI / CMS senza dover riscrivere il codice. Questo è il punto di partenza consigliato per qualsiasi codebase `next-intl` esistente.
+
+</Accordion>
+<Accordion header="Passa al nativo (next-intlayer)">
+
+Per nuovi progetti, o una volta che l'adattatore ha fatto il suo lavoro. È il più leggero dei tre (5.5 KB, +0.3 KB per pagina) e sblocca componenti server sincroni, file `.content.ts` per componente e l'intero set di funzionalità. Inizia con [Intlayer con Next.js](https://intlayer.org/it/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Il codice della mia applicazione rimane davvero intatto?">
+
+Su Next.js, sì per i componenti: la build di benchmark ha modificato solo `next.config.ts` e `intlayer.config.ts`. `getRequestConfig` in `src/i18n.ts`, la prop `messages` sul provider e le chiamate `pick()` per pagina diventano codice morto che puoi eliminare in seguito.
+
+</Question>
+
+<Question title="Cosa succede ai messaggi ICU?">
+
+Continuano a funzionare. `t("key", { count })`, `t.rich()`, `t.markup()`, `select`, `selectordinal`, `#` e `{ts, date, long}` vengono risolti dal risolutore ICU di Intlayer. Vedi [formato di messaggio ICU](https://intlayer.org/it/blog/icu-message-format).
+
+</Question>
+
+<Question title="Perché l'adattatore è più pesante di next-intlayer nativo?">
+
+Porta con sé la superficie API di `next-intl` sopra il core di Intlayer: `useFormatter`, `t.rich`, il risolutore ICU, gli helper di navigazione. Si tratta di 8.0 KB contro 5.5 KB, e +6 KB per pagina. È il ponte, non la destinazione finale.
+
+</Question>
+
+<Question title="Posso migrare componente per componente?">
+
+Sì. Qualsiasi componente può passare da `useTranslations("about")` a `useIntlayer("about")` con un file `.content.ts` co-locato. I dizionari JSON e `.content.ts` coesistono e si uniscono.
+
+</Question>
+
+<Question title="I percorsi localizzati (pathnames) funzionano?">
+
+Non tramite i `pathnames` di `next-intl`: l'adattatore li accetta per la tipizzazione ma non li interpola. Usa invece `routing.rewrite` di Intlayer, che emette i letterali localizzati nel registro dei tipi.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (le librerie, lo stesso benchmark)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (stessa serie di adapter)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (stessa serie di adapter)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (stessa serie di adapter)
-- [Guida alla migrazione: next-intl to Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [Riferimento adapter di compatibilità: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+Stessa serie di adattatori:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/it/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/it/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/it/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+Le librerie a confronto diretto:
+
+- [next-intl vs Intlayer](https://intlayer.org/it/blog/next-intl-vs-intlayer), stesso benchmark
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/it/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/it/blog/is-next-intl-outdated)
+
+Documenti di riferimento:
+
+- [Compat adapter: next-intl](https://intlayer.org/it/doc/compatibility/next-intl)
+- [Guida alla migrazione: da next-intl a Intlayer](https://intlayer.org/it/doc/migration/next-intl)
+- [Report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs) e [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- [Ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization) e [il compilatore Intlayer](https://intlayer.org/it/doc/compiler)
+- [Editor Visuale](https://intlayer.org/it/doc/concept/editor), [CMS](https://intlayer.org/it/doc/concept/cms) e [traduzione AI](https://intlayer.org/it/doc/concept/auto-fill)
 
 ## Conclusione
 

package/blog/it/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: Benchmark & Comparison 2026"
 description: Dimensione del bundle, perdita di contenuti, reattività del cambio locale e esperienza dello sviluppatore misurate su Next.js e TanStack Start. Quale libreria i18n dovresti scegliere nel 2026?
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Benchmark di Internazionalizzazione (i18n) per Next.js
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl` è la libreria i18n più popolare per Next.js. Intlayer è un'alternativa basata su compiler e component-scoped. Entrambi localizzano un'applicazione App Router. La domanda è quanto costi ciascuno una volta che l'app è compilata.
 
 Questo articolo non è un tutorial. È un confronto supportato da numeri da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite di benchmark open-source che compila la stessa applicazione con ciascuna libreria e misura ciò che il browser scarica effettivamente ed esegue.
@@ -96,6 +98,10 @@ Per ogni build, la suite registra:
 
 ### Risultati su Next.js (App Router)
 
+Seleziona le metriche e le librerie che ti interessano:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | ------------------------------ | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (no i18n)             | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -116,6 +122,15 @@ Per ogni build, la suite registra:
 - **Dimensione del componente.** Un componente che chiama `useTranslations()` compila in media a 21.8 KB; lo stesso componente con `useIntlayer()` compila a 6.9 KB. Nella configurazione `scoped-static` i componenti `next-intl` aumentano a 80.1 KB perché ognuno inserisce il suo catalogo di namespace.
 - **Reattività e idratazione** sono sullo stesso livello per entrambe le librerie su Next.js (15-18 ms). Nessuna è un collo di bottiglia qui.
 
+<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 [report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs).
+
 ### Risultati su TanStack Start (`use-intl`)
 
 `use-intl` è il core indipendente dal framework di `next-intl`. Stessa API, stesso formato di messaggio. Confrontarlo con `intlayer` su TanStack Start rimuove le parti specifiche di Next.js dall'equazione.
@@ -139,8 +154,19 @@ Per ogni build, la suite registra:
 - **La dimensione del componente è dove l'architettura si mostra**: 76-87 KB per componente con `use-intl` versus 6-8 KB con Intlayer. `useTranslations()` lega ogni componente all'albero dei messaggi globale; `useIntlayer()` lo lega al suo dizionario personale.
 - **Cambio di locale** è 2-4 volte più veloce con Intlayer (3 ms vs 7-21 ms).
 
+<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 [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack).
+
 ## Perché il divario? Cataloghi centralizzati 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)
+
 `next-intl` segue il modello classico: un JSON per locale, caricato in `getRequestConfig`, inserito in un `NextIntlClientProvider`, letto attraverso `t("namespace.key")`.
 
 ```bash
@@ -162,6 +188,10 @@ Per ogni build, la suite registra:
 
 Il runtime non può sapere quali chiavi una pagina utilizzerà, quindi il valore predefinito sicuro è inviare l'intero catalogo. Ottimizzare significa **tu** dividi il catalogo in namespace, **tu** decidi quali namespace ogni pagina ha bisogno, e **tu** mantieni quel mapping sincronizzato mentre i componenti si muovono. La riga `scoped-dynamic` del benchmark è la ricompensa per quel lavoro, e la maggior parte dei team non ci arriva mai.
 
+Il costo di non arrivarci cresce su due assi contemporaneamente, pagine e impostazioni locali:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer capovolge la responsabilità. Il contenuto è dichiarato accanto al componente:
 
 ```bash
@@ -189,7 +219,8 @@ Al momento della compilazione il compiler (`@intlayer/swc` / `@intlayer/babel`)
 
 ### Componente Client
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -224,7 +255,8 @@ export const Counter = () => {
 
 > Ricorda di includere il namespace `counter` nei messaggi passati a `NextIntlClientProvider` su ogni pagina che renderizza questo componente.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -265,11 +297,14 @@ export const Counter = () => {
 
 Niente da registrare sulla pagina: il componente porta con sé il suo contenuto.
 
+</Tab>
+</Tabs>
 ### Componente server sincrono
 
 I componenti design-system (navbar, footer, cards) sono spesso componenti server renderizzati come figli di componenti client, quindi non possono essere `async`.
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -287,7 +322,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 La pagina deve `await getTranslations("counter")` e `await getFormatter()`, quindi passare i risultati come props. Il componente non è più autonomo.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -308,9 +344,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### Metadati
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -344,7 +383,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -368,6 +408,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Mantieni l'API di next-intl, ottieni l'output di Intlayer
 
 Non devi riscrivere i componenti per ottenere i numeri di benchmark sopra. `@intlayer/next-intl` è un adattatore plug-and-play: mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, plurali ICU e gli helper di `next-intl/navigation`, e li serve dai dizionari Intlayer compilati dal compilatore Intlayer.
@@ -389,17 +432,84 @@ Consulta la [guida di migrazione next-intl](https://intlayer.org/doc/migration/n
 
 ## Quando scegliere quale?
 
-- **Scegli next-intl** se desideri lo standard dell'ecosistema per Next.js, dipendi da ICU MessageFormat, la tua app è di piccole o medie dimensioni, oppure ti integri con una piattaforma di traduzione (Crowdin, Phrase, Lokalise...) che prevede JSON centralizzati. Prevedi il tempo per namespace dei cataloghi e scegli messaggi per pagina se le prestazioni sono importanti.
-- **Scegli Intlayer** se desideri **contenuto con scope dei componenti**, **strict TypeScript**, **errori di chiavi mancanti in fase di build**, **tree-shaking e lazy loading senza sforzo**, server components sincroni, e tooling editoriale integrato (Visual Editor, CMS, traduzione AI, server MCP). Particolarmente rilevante per codebase grandi e modulari e design systems.
-- **Scegli `@intlayer/next-intl`** se sei già su `next-intl` e desideri i vantaggi di bundle senza una riscrittura completa.
+<AccordionGroup>
+<Accordion header="Scegli next-intl">
+
+Vuoi lo standard dell'ecosistema per Next.js, ti affidi a ICU MessageFormat, la tua app è di dimensioni medio-piccole o ti integri con una piattaforma di traduzione (Crowdin, Phrase, Lokalise...) che prevede JSON centralizzato. Considera il tempo per organizzare i cataloghi in namespace e selezionare i messaggi con `pick()` per pagina se le prestazioni contano.
+
+</Accordion>
+<Accordion header="Scegli Intlayer">
+
+Vuoi **contenuto con ambito per componente**, **TypeScript rigoroso**, **errori di chiavi mancanti in fase di compilazione**, **tree-shaking e caricamento lazy senza sforzo**, componenti server sincroni e strumenti editoriali integrati ([Editor Visuale](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 codebase modulari di grandi dimensioni e design system.
+
+</Accordion>
+<Accordion header="Scegli @intlayer/next-intl">
+
+Utilizzi già `next-intl` e desideri i vantaggi in termini di dimensioni del bundle senza dover riscrivere tutto. L'[adattatore di compatibilità](https://intlayer.org/it/doc/compatibility/next-intl) mantiene le importazioni e il file `messages/{locale}.json` come unica fonte di verità. Misurato fianco a fianco in [next-intl vs @intlayer/next-intl](https://intlayer.org/it/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="next-intl è più lento di Intlayer?">
+
+Non al momento del rendering. La differenza risiede in ciò che viene inviato al browser: `next-intl` costa **+12.6 KB gzip** di runtime su ogni pagina e, nelle configurazioni più comuni, invia ~90% delle stringhe di pagine esterne con ogni pagina. Il cambio di lingua e l'idratazione sono paragonabili su Next.js (15-18 ms); su TanStack Start, `use-intl` impiega 7-21 ms contro i 3-4 ms di Intlayer.
+
+</Question>
+
+<Question title="Posso raggiungere lo 0% di dispersione con next-intl?">
+
+Sì, con la configurazione `scoped-dynamic`: dividi `messages/{locale}.json` in un namespace per route, quindi usa `pick(messages, [...])` in ogni pagina e mantieni corretta questa mappatura man mano che i componenti cambiano. Le righe `scoped-*` del benchmark rappresentano proprio questo lavoro. Intlayer raggiunge lo 0% senza tutto questo perché il compilatore isola il contenuto per componente. Consulta [ottimizzazione del bundle](https://intlayer.org/it/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Devo riscrivere i miei componenti per migrare?">
+
+No. `@intlayer/next-intl` mantiene `useTranslations`, `getTranslations`, `useFormatter`, `t.rich()`, i plurali ICU e gli helper di navigazione, e li fornisce da dizionari compilati. Una sola riga di plugin in `next.config.ts`. Passo dopo passo nella [guida alla migrazione di next-intl](https://intlayer.org/it/doc/migration/next-intl).
+
+</Question>
+
+<Question title="Intlayer supporta ICU MessageFormat?">
+
+Il supporto nativo ICU è in fase di sviluppo sull'API principale. Gli adattatori di compatibilità (`@intlayer/next-intl`, `@intlayer/use-intl`) eseguono già ICU: plurali, `select`, `selectordinal`, `#` e `{ts, date, long}` passano attraverso il risolutore ICU di Intlayer. Leggi [formato di messaggio ICU](https://intlayer.org/it/blog/icu-message-format) per i dettagli.
+
+</Question>
+
+<Question title="Posso conservare i miei file messages/{locale}.json?">
+
+Sì. Il [plugin di sincronizzazione JSON](https://intlayer.org/it/doc/compatibility/next-intl) li legge, divide le chiavi di livello superiore in dizionari e riscrive le traduzioni negli stessi file quando la CLI o il CMS li aggiorna. Il flusso di lavoro dei tuoi traduttori non cambia.
+
+</Question>
+
+</FAQ>
 
 ## Confronti correlati
 
-- [i18next vs Intlayer](https://intlayer.org/blog/i18next-vs-intlayer) (stesso benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/blog/lingui-vs-intlayer) (stesso benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (stesso benchmark)
-- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [next-intl è obsoleto?](https://intlayer.org/blog/is-next-intl-outdated)
+Stesso benchmark, altre librerie:
+
+- [i18next vs Intlayer](https://intlayer.org/it/blog/i18next-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)
+
+Approfondimenti su next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/it/blog/next-intl-vs-intlayer-next-intl), l'adattatore misurato sulla stessa applicazione
+- [Is next-intl outdated?](https://intlayer.org/it/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/it/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/it/blog/nextjs-internationalization-using-next-intl)
+
+Documenti di riferimento:
+
+- [Report di benchmark Next.js](https://intlayer.org/it/doc/benchmark/nextjs) e [report di benchmark TanStack Start](https://intlayer.org/it/doc/benchmark/tanstack)
+- [Adattatore di compatibilità: next-intl](https://intlayer.org/it/doc/compatibility/next-intl) e [guida alla migrazione](https://intlayer.org/it/doc/migration/next-intl)
+- [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)
 
 ## Star su GitHub
 

package/blog/it/transform_existing_vite_react_app_using_compiler.md

@@ -289,7 +289,9 @@ const pathList = [
   { path: "/about", changefreq: "monthly", priority: 0.7 },
 ];
 
-const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+const sitemapXml = generateSitemap(pathList, {
+  siteUrl: "https://example.com",
+});
 fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
 
 const getAllMultilingualUrls = (urls) =>
@@ -302,7 +304,7 @@ const robotsTxt = [
   "Allow: /",
   ...disallowedPaths.map((path) => `Disallow: ${path}`),
   "",
-  `Sitemap: ${SITE_URL}/sitemap.xml`,
+  `Sitemap: https://example.com/sitemap.xml`,
 ].join("\n");
 
 fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);