next-intl VS Intlayer: Benchmark di Internazionalizzazione (i18n) per Next.js

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, una suite di benchmark open-source che compila la stessa applicazione con ciascuna libreria e misura ciò che il browser scarica effettivamente ed esegue.

tl;dr: Sulla stessa app Next.js, next-intl aggiunge +12.6 KB gzip di JavaScript su ogni pagina, rispetto ai +0.3 KB di Intlayer. Senza lavoro extra, next-intl spedisce ~90% delle stringhe di pagine straniere con ogni pagina. Raggiungere lo 0% di leakage con next-intl richiede namespace scoping e per-page pick(messages, [...]). Intlayer raggiunge lo 0% di default, perché il suo compiler definisce l'ambito dei contenuti per componente. Se vuoi l'API di next-intl con l'output di Intlayer, l'adapter @intlayer/next-intl ha misurato 147.5 KB per pagina rispetto ai 153.6 KB con l'originale.

In breve

• next-intl - Leggero, ben documentato, supporto per il formato di messaggi ICU, supporto di first-class per App Router con middleware, formattatori e helper di navigazione. I contenuti risiedono in cataloghi JSON centralizzati; le ottimizzazioni delle prestazioni (namespace, selezione dei messaggi per pagina, lazy loading) sono a tua responsabilità.
• Intlayer - Modello di contenuto incentrato sui componenti. I dizionari .content.ts si trovano accanto al componente che servono, un compiler in fase di build tree-shake e lazy-load per ogni componente e per ogni locale, i tipi TypeScript rigorosi sono generati dal tuo contenuto, e le traduzioni mancanti falliscono in fase di build. Include middleware, helper SEO, un Visual Editor / CMS e traduzione assistita dall'IA.

Mostra tutto il contenuto della tabella

Mostra tutto il contenuto della tabella

Apri la tabella in una finestra modale per visualizzare tutti i dati in modo chiaro

Libreria	Stelle GitHub	Commit Totali	Ultimo Commit	Prima Versione	Versione NPM	Download NPM
aymericzip/intlayer				Aprile 2024
amannn/next-intl				Nov 2020

I badge si aggiornano automaticamente. Gli snapshot varieranno nel tempo.

Confronto delle funzionalità fianco a fianco

Il benchmark

Cosa è stato misurato

La suite Benchmark Bloom costruisce la stessa applicazione con ogni libreria: 10 pagine (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 locali (en, fr, es, de, it, pt, zh, ja, ko, ru), componenti identici e contenuti identici. Le pagine vengono misurate in en e fr. Ogni libreria è implementata in fino a quattro strategie di caricamento, dal setup naive a quello ottimale:

Intlayer non ha una variante "scoped": il compiler delimita il contenuto per componente automaticamente, quindi le sue righe static e dynamic sono già scoped.

Per ogni build, la suite registra:

• Lib size: dimensione gzip della libreria i18n in un componente vuoto che la importa solo. Il costo fisso del runtime.
• Page JS: JavaScript gzip scaricato per pagina, mediato su tutte le pagine e i locale.
• Locale leak %: quota di stringhe tradotte trovate nel JS scaricato che appartengono a un locale che l'utente non sta visualizzando (fingerprinted su en e fr, quindi il 50% significa "l'altro locale misurato è completamente presente"; con 10 locale raggruppati, lo spreco reale è maggiore).
• Page leak %: quota di stringhe tradotte trovate nel JS scaricato che appartengono a una pagina su cui l'utente non si trova.
• Component avg: dimensione media gzip di ogni componente compilato in isolamento. Mostra quanto runtime i18n un singolo componente introduce.
• E2E reactivity: tempo reale tra la selezione di una nuova locale e l'aggiornamento di html[lang] nel DOM (Playwright, 5 iterazioni).
• Hydration: durata della fase di hydration di React.

I numeri sottostanti provengono dall'esecuzione datata 2026-09-12 con next-intl 4.14.2, use-intl 4.14.2 e intlayer 9.5.1. L'applicazione di test è deliberatamente piccola (poche dozzine di stringhe per locale), quindi le percentuali di dispersione descrivono un pattern: crescono con i tuoi contenuti mentre il costo runtime rimane fisso.

Risultati su Next.js (App Router)

Seleziona le metriche e le librerie che ti interessano:

Come leggerlo

• Costo runtime. L'applicazione di base pesa 141.0 KB per pagina. next-intl la porta a 153.6 KB (+12.6 KB gzip su ogni pagina), Intlayer a 141.3 KB (+0.3 KB). Questo divario non dipende da quante stringhe hai: è il runtime della libreria.
• Leakage. Nei due setup che la maggior parte dei team effettivamente distribuisce (static e dynamic), next-intl consegna ~90% delle stringhe di pagine straniere con ogni pagina: l'intero en.json viene inserito nel provider client. Per arrivare a 0% è necessario utilizzare i setup scoped-*: dividere i cataloghi in namespace, quindi pick() quelli corretti in ogni pagina. Intlayer è al 0% in entrambe le righe senza nulla di tutto ciò.
• Il JS per pagina non si è mosso per next-intl tra le strategie. Il contenuto del test è piccolo, quindi la leakage ~90% è solo di pochi KB qui. Su un'app reale con centinaia di stringhe per pagina, quel rapporto diventa il costo dominante. Nel frattempo il runtime +12.6 KB viene pagato in ogni configurazione.
• 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.

Tabella completa, ogni libreria e ogni strategia, nel report di benchmark Next.js.

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.

Come leggerlo

• La configurazione naive di use-intl invia 68.8 KB di JS in più per pagina rispetto all'app base, con metà delle stringhe appartenenti alla locale sbagliata e il 90% alla pagina sbagliata.
• use-intl in modalità dynamic arriva a 119.4 KB, vicino ai 118.6 KB di Intlayer, ma comunque mantiene 89.8% di page leakage: tutte le stringhe delle pagine per la locale attiva vengono caricate su ogni pagina. Circoscriverle per route (scoped-*) rimuove la perdita ma costa altri ~9 KB di overhead del chunk.
• La riga static di Intlayer ha già 0% di page leakage: il compiler raggruppa solo i dizionari utilizzati dai componenti sulla pagina. Abilitando importMode: 'dynamic' (una riga in intlayer.config.ts) rimuove anche la locale leakage.
• 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).

Tabella completa nel report di benchmark TanStack Start.

Perché il divario? Cataloghi centralizzati vs. dizionari compilati

next-intl segue il modello classico: un JSON per locale, caricato in getRequestConfig, inserito in un NextIntlClientProvider, letto attraverso t("namespace.key").

.
├── messages
│   ├── en.json
│   └── fr.json
└── src
    ├── i18n
    │   ├── request.ts
    │   └── routing.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                └── page.tsx

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:

Intlayer capovolge la responsabilità. Il contenuto è dichiarato accanto al componente:

.
├── intlayer.config.ts
└── src
    ├── middleware.ts
    ├── app
    │   └── [locale]
    │       ├── layout.tsx
    │       └── about
    │           ├── page.tsx
    │           └── page.content.ts
    └── components
        └── Counter
            ├── index.tsx
            └── index.content.ts

Al momento della compilazione il compiler (@intlayer/swc / @intlayer/babel) vede quale componente importa quale dizionario. Raggruppa solo i dizionari utilizzati, solo per la locale attiva, e scarta quelli che nessuno importa. Il pattern "scoped-dynamic" diventa l'output della build invece di essere una disciplina che il team deve mantenere.

Per ottenere i numeri della riga dynamic, imposta dictionary.importMode: 'dynamic' in intlayer.config.ts. Vedi la documentazione di ottimizzazione del bundle.

Esperienza dello sviluppatore

Componente Client

{
  "counter": {
    "label": "Counter",
    "increment": "Increment"
  }
}

"use client";

import { useState } from "react";
import { useTranslations, useFormatter } from "next-intl";

export const Counter = () => {
  const t = useTranslations("counter");
  const format = useFormatter();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{format.number(count)}</p>
      <button aria-label={t("label")} onClick={() => setCount((c) => c + 1)}>
        {t("increment")}
      </button>
    </div>
  );
};

import { t, type Dictionary } from "intlayer";

const counterContent = {
  key: "counter",
  content: {
    label: t({ it: "Contatore", en: "Counter", fr: "Compteur" }),
    increment: t({ it: "Incrementa", en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

"use client";

import { useState } from "react";
import { useIntlayer } from "next-intlayer";
import { useNumber } from "next-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

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.

type ServerCounterProps = {
  t: (key: string) => string;
  formattedCount: string;
};

export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
  <div>
    <p>{formattedCount}</p>
    <button aria-label={t("label")}>{t("increment")}</button>
  </div>
);

import { useIntlayer } from "next-intlayer/server";

</div>
import { useNumber } from "next-intlayer/server/format";

export const ServerCounter = ({ count }: { count: number }) => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label}>{increment}</button>
    </div>
  );
};

Metadati

import type { Metadata } from "next";
import { getTranslations } from "next-intl/server";
import { routing } from "@/i18n/routing";

// Crea un percorso localizzato basato sulla locale
const localizedPath = (locale: string, path: string) =>
  locale === routing.defaultLocale ? path : `/${locale}${path}`;

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: "about" });

  const languages = Object.fromEntries(
    routing.locales.map((l) => [l, localizedPath(l, "/about")])
  );

  return {
    title: t("title"),
    description: t("description"),
    alternates: {
      canonical: localizedPath(locale, "/about"),
      languages: { ...languages, "x-default": "/about" },
    },
  };
};

import { getIntlayer, getMultilingualUrls } from "intlayer";
import type { Metadata } from "next";
import type { LocalPromiseParams } from "next-intlayer";

export const generateMetadata = async ({
  params,
}: LocalPromiseParams): Promise<Metadata> => {
  const { locale } = await params;
  const metadata = getIntlayer("about-metadata", locale);
  const multilingualUrls = getMultilingualUrls("/about");

  return {
    ...metadata,
    alternates: {
      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],
      languages: { ...multilingualUrls, "x-default": "/about" },
    },
  };
};

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.

import type { NextConfig } from "next";
import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

Nel benchmark, la build di compatibilità della stessa app è passata da 153.6 KB a 147.5 KB per pagina, da 21.8 KB a 8.1 KB per componente, e da ~90% page leakage a 0%, senza modificare il codice dell'applicazione. I tuoi file messages/{locale}.json esistenti possono rimanere la fonte di verità attraverso il plugin JSON sync.

Consulta la guida di migrazione next-intl per le istruzioni passo dopo passo.

Quando scegliere quale?

FAQ

Confronti correlati

Stesso benchmark, altre librerie:

Approfondimenti su next-intl:

Documenti di riferimento:

Per capire da dove vengono queste librerie, leggi la storia dell'i18n in JavaScript.

Star su GitHub

Le star su GitHub sono un forte indicatore della popolarità di un progetto, della fiducia della comunità e della rilevanza a lungo termine. Anche se non sono una misura diretta della qualità tecnica, riflettono quanti developer trovano il progetto utile, seguono il suo progresso e sono propensi ad adottarlo.

Attività dei commit

Le stelle indicano la popolarità. I commit indicano quanto lavoro viene investito in un progetto. Al momento della scrittura, Intlayer conta circa 7.500 commit, più della maggior parte delle librerie confrontate qui e circa 5 volte più di next-intl o next-i18next.

Intlayer è un monorepo, quindi il totale include ogni pacchetto framework, la CLI e la documentazione. Leggi i commit come un segnale di attività, non di qualità.

Download npm

I download premiano le soluzioni più vecchie, non le migliori. Una libreria pubblicata anni fa viene ancora installata da ogni progetto che l'ha scelta allora, da ogni esecuzione della CI e da ogni pacchetto che ne dipende. Il numero misura l'inerzia più che una scelta attuale.

Gli assistenti IA amplificano l'effetto. next-intl, i18next e vue-i18n sono ovunque nel codice su cui sono stati addestrati, quindi li suggeriscono di default, senza confrontare le alternative. Ogni suggerimento aggiunge download, che alimentano il suggerimento successivo. Confronta sul benchmark, non sul numero di download.

Conclusione

next-intl è una libreria solida e ben mantenuta, e il benchmark conferma che è tutt'altro che la peggiore opzione su Next.js. Tuttavia, il suo modello di catalogo centralizzato mette ogni ottimizzazione nelle mani dello sviluppatore: la configurazione ingenua fa filtrare ~90% dei contenuti delle pagine straniere, e il runtime da solo costa +12,6 KB gzip su ogni pagina.

Intlayer sposta quel lavoro nel compiler. Dizionari per-componente, lazy loading per-locale e purging del contenuto non utilizzato sono output di build, non convenzioni. Il risultato sulla stessa app: +0.3 KB per pagina, 0% leakage, componenti 3x più piccoli, e uno switch locale 2x-4x più veloce su TanStack Start.

Tutti i dati grezzi, le app di test e gli script si trovano nel repository Benchmark Bloom. Eseguilo tu stesso.

Fai riferimento al documento 'Why Intlayer?' per maggiori dettagli.