next-intl VS Intlayer | Benchmark de Internacionalização (i18n) do Next.js

next-intl é a biblioteca i18n mais popular para Next.js. Intlayer é uma alternativa baseada em compilador e com escopo de componente. Ambas localizam uma aplicação App Router. A questão é quanto cada uma custa uma vez que a aplicação está compilada.

Este artigo não é um tutorial. É uma comparação apoiada por números do Benchmark Bloom, um conjunto de benchmark open-source que constrói a mesma aplicação com cada biblioteca e mede o que o navegador realmente faz download e executa.

tl;dr: Na mesma aplicação Next.js, next-intl adiciona +12.6 KB gzip de JavaScript em cada página, versus +0.3 KB para Intlayer. Sem trabalho extra, next-intl envia ~90% das strings de páginas estrangeiras com cada página. Alcançar 0% de vazamento com next-intl requer escopo de namespace e pick(messages, [...]) por página. Intlayer alcança 0% por padrão, porque seu compiler escopeia o conteúdo por componente. Se você quer a API next-intl com a saída do Intlayer, o adaptador @intlayer/next-intl mediu 147.5 KB por página versus 153.6 KB com o original.

Em resumo

• next-intl - Leve, bem documentado, formato de mensagem ICU, suporte de primeira classe ao App Router com middleware, formatters e helpers de navegação. O conteúdo reside em catálogos JSON centralizados; otimizações de desempenho (namespaces, seleção de mensagens por página, lazy loading) são sua responsabilidade.
• Intlayer - Modelo de conteúdo centrado em componentes. Dicionários .content.ts ficam ao lado do componente que servem, um compilador em tempo de build faz tree-shake e lazy-loads deles por componente e por locale, tipos TypeScript rigorosos são gerados a partir do seu conteúdo, e traduções ausentes falham em tempo de build. Inclui middleware, helpers de SEO, um Visual Editor / CMS e tradução assistida por IA.

Mostrar todo o conteúdo da tabela

Mostrar todo o conteúdo da tabela

Abrir a tabela em um modal para ver todo o conteúdo claramente

Biblioteca	Estrelas do GitHub	Total de Commits	Último Commit	Primeira Versão	Versão NPM	Downloads NPM
aymericzip/intlayer				Abril 2024
amannn/next-intl				Nov 2020

Os emblemas são atualizados automaticamente. Os snapshots variarão ao longo do tempo.

Comparação de recursos lado a lado

O benchmark

O que foi medido

O suite Benchmark Bloom constrói a mesma aplicação com cada biblioteca: 10 páginas (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 locales (en, fr, es, de, it, pt, zh, ja, ko, ru), componentes idênticos e conteúdo idêntico. As páginas são medidas em en e fr. Cada biblioteca é implementada em até quatro estratégias de carregamento, da configuração ingênua até a otimizada:

Intlayer não possui uma variante "scoped": o compilador agrupa conteúdo por componente automaticamente, então suas linhas static e dynamic já estão agrupadas.

Para cada build, a suite registra:

• Lib size: tamanho gzip da biblioteca i18n. O custo fixo do runtime.
• Page JS: JavaScript gzip baixado por página, calculado em média sobre todas as páginas e locales.
• Locale leak %: proporção de strings traduzidas encontradas no JS baixado que pertencem a um locale que o usuário não está visualizando (fingerprinted em en e fr, então 50% significa "o outro locale medido está totalmente presente"; com 10 locales agrupados, o desperdício real é maior).
• Page leak %: proporção de strings traduzidas encontradas no JS baixado que pertencem a uma página em que o usuário não está.
• Component avg: tamanho gzip médio de cada componente compilado isoladamente. Mostra quanto runtime i18n um único componente carrega.
• E2E reactivity: tempo real entre selecionar uma nova locale e html[lang] atualizar no DOM (Playwright, 5 iterações).
• Hydration: duração da fase de hidratação do React.

Os números abaixo vêm da execução datada de 2026-09-12 com next-intl 4.14.2, use-intl 4.14.2 e intlayer 9.5.1. A aplicação de teste é deliberadamente pequena (algumas dezenas de strings por locale), portanto as porcentagens de vazamento descrevem um padrão: eles crescem com seu conteúdo enquanto o custo de runtime permanece fixo.

Resultados no Next.js (App Router)

Como ler isso

• Custo de runtime. A aplicação base pesa 141.0 KB por página. next-intl a leva para 153.6 KB (+12.6 KB gzip em cada página), Intlayer para 141.3 KB (+0.3 KB). Esta diferença não depende de quantas strings você tem: é o runtime da biblioteca.
• Vazamento. Nos dois setups que a maioria das equipes realmente implementa (static e dynamic), next-intl entrega ~90% das strings de páginas estrangeiras com cada página: todo o en.json vai para o provider do cliente. Para chegar a 0% é necessário os setups scoped-*: dividir catálogos em namespaces e depois fazer pick() dos corretos em cada página. Intlayer está em 0% em ambas as linhas sem nada disso.
• O JS por página não se moveu para next-intl entre estratégias. O conteúdo do teste é pequeno, então o vazamento de ~90% é apenas alguns KB aqui. Em uma app real com centenas de strings por página, essa proporção se torna o custo dominante. Enquanto isso, o runtime de +12.6 KB é pago em cada configuração.
• Tamanho do componente. Um componente que chama useTranslations() compila para 21.8 KB em média; o mesmo componente com useIntlayer() compila para 6.9 KB. Na configuração scoped-static, os componentes next-intl saltam para 80.1 KB porque cada um internaliza seu catálogo de namespace.
• Reatividade e hidratação estão no mesmo patamar para ambas as bibliotecas no Next.js (15-18 ms). Nenhuma delas é um gargalo aqui.

Resultados no TanStack Start (use-intl)

use-intl é o núcleo agnóstico de framework do next-intl. Mesma API, mesmo formato de mensagem. Comparar isso contra intlayer no TanStack Start remove as partes específicas do Next.js da equação.

Como ler isso

• A configuração ingênua use-intl envia 68.8 KB a mais de JS por página do que a aplicação base, com metade das strings pertencendo à locale errada e 90% à página errada.
• use-intl em modo dynamic chega a 119.4 KB, próximo ao 118.6 KB do Intlayer, mas ainda carrega 89.8% de vazamento de página: as strings de todas as páginas para a locale ativa são carregadas em cada página. Escopo-las por rota (scoped-*) remove o vazamento, mas custa outro ~9 KB de overhead de chunk.
• Intlayer's static já tem 0% de vazamento de página: o compilador só agrupa os dicionários usados pelos componentes na página. Habilitando importMode: 'dynamic' (uma linha em intlayer.config.ts) remove também o vazamento de locale.
• O tamanho do componente é onde a arquitetura se manifesta: 76-87 KB por componente com use-intl versus 6-8 KB com Intlayer. useTranslations() vincula cada componente à árvore de mensagens global; useIntlayer() vincula-o ao seu próprio dicionário.
• Mudança de locale é 2x-4x mais rápida com Intlayer (3 ms vs 7-21 ms).

Por que a diferença? Catálogos centralizados vs. dicionários compilados

next-intl segue o modelo clássico: um JSON por locale, carregado em getRequestConfig, inserido em um NextIntlClientProvider, lido através de t("namespace.key").

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

O runtime não consegue saber quais keys uma página usará, então o padrão seguro é enviar o catálogo completo. Otimizar significa você dividir o catálogo em namespaces, você decidir quais namespaces cada página precisa, e você manter esse mapeamento sincronizado conforme os componentes se movem. A linha scoped-dynamic do benchmark é a recompensa por esse trabalho, e a maioria das equipes nunca chega lá.

Intlayer inverte a responsabilidade. O conteúdo é declarado ao lado do componente:

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

No momento da compilação, o compilador (@intlayer/swc / @intlayer/babel) vê qual componente importa qual dicionário. Ele agrupa apenas esses dicionários, apenas para o locale ativo, e descarta os que nada importa. O padrão "scoped-dynamic" torna-se a saída da compilação em vez de uma disciplina que o time tem que manter.

Para obter os números da linha dynamic, defina dictionary.importMode: 'dynamic' em intlayer.config.ts. Veja a documentação de otimização de bundle.

Experiência do desenvolvedor

Componente cliente

next-intl

{
  "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>
  );
};

Lembrez-se de incluir o namespace counter nas mensagens passadas para NextIntlClientProvider em cada página que renderiza este componente.

Intlayer

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

const counterContent = {
  key: "counter",
  content: {
    label: t({ pt: "Contador", en: "Counter", fr: "Compteur" }),
    increment: t({ pt: "Incrementar", 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 = () => {
  // Obter o rótulo e o texto do incremento do conteúdo da internacionalização
  const { label, increment } = useIntlayer("counter");
  // Obter a função de formatação de números
  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>
  );
};

Nada para registrar na página: o componente traz seu próprio conteúdo.

Componente de servidor síncrono

Peças de design-system (navbar, footer, cards) são frequentemente componentes server renderizados como children de componentes client, então não podem ser async.

next-intl

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>
);

A página tem que await getTranslations("counter") e await getFormatter(), depois passar os resultados para baixo como props. O componente não é mais auto-contido.

Intlayer

import { useIntlayer } from "next-intlayer/server";
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>
  );
};

Metadados

next-intl

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

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" },
    },
  };
};

Intlayer

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" },
    },
  };
};

Mantenha a API do next-intl, obtenha a saída do Intlayer

Você não precisa reescrever componentes para obter os números de benchmark acima. @intlayer/next-intl é um adaptador pronto para usar: mantém useTranslations, getTranslations, useFormatter, t.rich(), plurais ICU e os auxiliares next-intl/navigation, e os fornece a partir dos dicionários compilados do Intlayer pelo compilador Intlayer.

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

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

Na benchmark, a build de compatibilidade da mesma aplicação passou de 153.6 KB para 147.5 KB por página, de 21.8 KB para 8.1 KB por componente, e de ~90% page leakage para 0%, com o código da aplicação intacto. Seus arquivos messages/{locale}.json existentes podem continuar sendo a fonte de verdade através do plugin JSON sync.

Veja o guia de migração next-intl para o passo a passo.

Quando escolher qual?

• Escolha next-intl se você quer o padrão de ecossistema para Next.js, depende de ICU MessageFormat, sua aplicação é pequena a média, ou você se integra com uma plataforma de tradução (Crowdin, Phrase, Lokalise...) que espera JSON centralizado. Considere o tempo para namespace de catálogos e selecione mensagens por página se o desempenho importa.
• Escolha Intlayer se você quer conteúdo com escopo de componente, TypeScript rigoroso, erros de chaves ausentes em tempo de build, tree-shaking e lazy loading sem esforço, componentes de servidor síncronos, e ferramentas editoriais integradas (Visual Editor, CMS, tradução com IA, servidor MCP). Especialmente relevante para codebases grandes e modulares e design systems.
• Escolha @intlayer/next-intl se você já está usando next-intl e quer ganhos de bundle sem uma reescrita.

Comparações relacionadas

• i18next vs Intlayer (mesmo benchmark)
• Lingui vs Intlayer (mesmo benchmark)
• vue-i18n vs Intlayer benchmark (mesmo benchmark)
• next-i18next vs next-intl vs Intlayer
• next-intl está desatualizado?

GitHub STARs

As estrelas do GitHub são um forte indicador de popularidade de um projeto, confiança da comunidade e relevância de longo prazo. Embora não sejam uma medida direta de qualidade técnica, elas refletem quantos desenvolvedores acham o projeto útil, acompanham seu progresso e provavelmente vão adotá-lo.

Conclusão

next-intl é uma biblioteca sólida e bem mantida, e o benchmark confirma que está longe de ser a pior opção no Next.js. Mas seu modelo de catálogo centralizado coloca cada otimização nas mãos do desenvolvedor: a configuração ingênua vaza ~90% do conteúdo de páginas estrangeiras, e o runtime sozinho custa +12.6 KB gzip em cada página.