Next-intl library integration in NextJS - Performance & Optimization

Performance: Next-intl library integration

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by how translations are loaded and rendered in Next.js apps.

Loading translations for a Next.js page

NextJS

import {getTranslations} from 'next-intl/server';

export async function generateStaticParams() {
  return [{locale: 'en'}, {locale: 'fr'}];
}

export default async function Page({params}) {
  const t = await getTranslations(params.locale);
  return <p>{t('welcome')}</p>;
}

// Translations loaded server-side or statically

Translations are included in server-rendered HTML, enabling faster first meaningful paint and better LCP.

📈 Performance GainReduces LCP by 200-400ms by avoiding client-side translation fetching

Loading translations for a Next.js page

NextJS

'use client';
import {useTranslations} from 'next-intl';

export default function Page() {
  const t = useTranslations();
  return <p>{t('welcome')}</p>;
}

// Translations fetched client-side after page load

Translations load on the client after initial HTML, causing delayed text rendering and worse LCP.

📉 Performance CostBlocks meaningful content paint until translations load, increasing LCP by 200-400ms

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Client-side translation fetching	Minimal DOM nodes added	Triggers 1 reflow after translations load	Delays paint by 200-400ms	[X] Bad
Server-side or static translation loading	Minimal DOM nodes added	Single reflow during initial paint	Paints immediately with translations	[OK] Good

Rendering Pipeline

Next-intl translations loaded server-side are injected during HTML generation, so the browser receives fully translated content immediately. Client-side fetching delays translation injection until after hydration.

→HTML Generation

→Layout

→Paint

⚠️ BottleneckPaint stage is delayed if translations load client-side

Core Web Vital Affected

LCP

This affects page load speed and interaction responsiveness by how translations are loaded and rendered in Next.js apps.

Optimization Tips

1Load translations server-side or statically to improve LCP.

2Avoid client-side translation fetching to prevent delayed content paint.

3Use Next.js static generation or server rendering features with next-intl for best performance.

Performance Quiz - 3 Questions

What is the main performance benefit of loading translations server-side with next-intl in Next.js?

A Improves Largest Contentful Paint by including translations in initial HTML

B Reduces JavaScript bundle size by removing translation code

C Speeds up client-side hydration by delaying translation loading

D Eliminates the need for CSS styles for translated text

DevTools: Performance

How to check: Record a page load in DevTools Performance panel, then look for the time between navigation start and first meaningful paint. Check if translation text appears immediately or after a delay.

What to look for: Look for delayed text content rendering indicating client-side translation fetching, which worsens LCP.

Practice

1. What is the main purpose of the NextIntlProvider component in a Next.js app using next-intl?

easy

A. To fetch data from an API

B. To provide translation messages and locale context to the app

C. To handle routing between pages

D. To style components with CSS

Solution

1. Step 1: Understand the role of NextIntlProvider

   The NextIntlProvider wraps the app and supplies translation messages and locale information to all child components.

2. Step 2: Compare with other options

   Fetching data, routing, and styling are unrelated to NextIntlProvider's purpose.

3. Final Answer:

   To provide translation messages and locale context to the app -> Option B

4. Quick Check:

   NextIntlProvider = translation context provider [OK]

Hint: NextIntlProvider always wraps your app to share translations [OK]

Common Mistakes:

• Confusing NextIntlProvider with data fetching
• Thinking it handles routing or styling
• Not realizing it shares locale and messages

2. Which of the following is the correct way to import and use the useTranslations hook in a Next.js component?

easy

A. import { useTranslations } from 'next-intl'; const t = useTranslations('common');

B. import useTranslations from 'next-intl'; const t = useTranslations('common');

C. import { useTranslations } from 'next-intl'; const t = useTranslations();

D. import { useTranslation } from 'next-intl'; const t = useTranslation('common');

Solution

1. Step 1: Check correct import syntax

   The hook is named useTranslations and imported with curly braces from 'next-intl'.

2. Step 2: Verify usage with namespace

   It requires a namespace string like 'common' to get translations from that section.

3. Final Answer:

   import { useTranslations } from 'next-intl'; const t = useTranslations('common'); -> Option A

4. Quick Check:

   Correct import and call with namespace = import { useTranslations } from 'next-intl'; const t = useTranslations('common'); [OK]

Hint: Always import with braces and pass namespace string [OK]

Common Mistakes:

• Importing without braces
• Calling useTranslations without arguments
• Using wrong hook name useTranslation

3. Given this component using next-intl:

import { useTranslations } from 'next-intl';

export default function Greeting() {
  const t = useTranslations('greeting');
  return <h1>{t('hello')}</h1>;
}

If the messages for locale 'en' are { greeting: { hello: 'Hello, friend!' } }, what will be rendered?

medium

A. An error because 'hello' key is missing

B. <h1>greeting.hello</h1>

C. <h1>Hello, friend!</h1>

D. <h1>Hello</h1>

Solution

1. Step 1: Understand useTranslations usage

   The hook useTranslations('greeting') accesses the 'greeting' namespace in messages.

2. Step 2: Check message key 'hello'

   The key 'hello' inside 'greeting' is 'Hello, friend!'. So t('hello') returns that string.

3. Final Answer:

   <h1>Hello, friend!</h1> -> Option C

4. Quick Check:

   Namespace + key returns correct text = <h1>Hello, friend!</h1> [OK]

Hint: Namespace + key in messages gives displayed text [OK]

Common Mistakes:

• Expecting raw keys instead of translated text
• Assuming missing keys cause errors
• Confusing namespace with key

4. You wrote this code in a Next.js page:

import { NextIntlProvider } from 'next-intl';

export default function Page({ messages }) {
  return (
    <NextIntlProvider messages={messages} locale="en">
      <h1>Welcome</h1>
    </NextIntlProvider>
  );
}

But you get an error: "messages is undefined". What is the likely cause?

medium

A. You forgot to load and pass messages as a prop to the Page component

B. NextIntlProvider does not accept a messages prop

C. Locale must be passed as a number, not a string

D. You must import useTranslations instead of NextIntlProvider

Solution

1. Step 1: Check messages prop usage

   The NextIntlProvider requires a valid messages object passed as a prop.

2. Step 2: Identify cause of undefined

   If messages is undefined, it means the parent or data loader did not supply it properly.

3. Final Answer:

   You forgot to load and pass messages as a prop to the Page component -> Option A

4. Quick Check:

   Missing messages prop causes undefined error [OK]

Hint: Always load and pass messages before using NextIntlProvider [OK]

Common Mistakes:

• Thinking NextIntlProvider doesn't need messages
• Passing locale as number instead of string
• Confusing hooks with provider component

5. You want to support English and Spanish in your Next.js app using next-intl. You have message files:

locales/en.json
locales/es.json

How should you structure your app/layout.tsx to load messages dynamically and provide translations to all pages?

hard

A. Load messages inside each page component instead of layout

B. Import both JSON files statically and pass both to NextIntlProvider at once

C. Use useTranslations in layout to load messages and pass to children

D. Use async function to load messages based on locale, then wrap children with NextIntlProvider passing loaded messages and locale

Solution

1. Step 1: Understand dynamic message loading

   To support multiple locales, load messages dynamically based on the current locale in an async layout or provider.

2. Step 2: Wrap app with NextIntlProvider

   Pass the loaded messages and locale to NextIntlProvider wrapping all children so translations are available app-wide.

3. Final Answer:

   Use async function to load messages based on locale, then wrap children with NextIntlProvider passing loaded messages and locale -> Option D

4. Quick Check:

   Dynamic loading + provider wrapping = Use async function to load messages based on locale, then wrap children with NextIntlProvider passing loaded messages and locale [OK]

Hint: Load messages async by locale, wrap app with NextIntlProvider [OK]

Common Mistakes:

• Importing all locales at once statically
• Loading messages inside pages instead of layout
• Using useTranslations to load messages