Lesson 22 of 81

Font Optimization with next/font

Q: Your team currently loads a custom Google Font with a tag in the HTML head. A teammate proposes switching to next/font/google and says it will "make fonts load faster." Is that the right justification, and what would you actually tell them changes?

A strong answer covers: Identifies that next/font self-hosts the font by downloading it at build time, so the browser never makes a runtime request to Google Fonts; Explains this removes both a privacy leak (visitor IP sent to Google) and a network round trip, distinct from just 'faster'; Connects it to layout shift specifically — build-time knowledge of font metrics lets Next.js size an automatic fallback font to avoid reflow; Recognizes 'faster' alone undersells it — the concrete mechanisms are self-hosting and layout-shift prevention, not a vague speed claim.

A `<link>` to Google Fonts looks free, but it costs a render-blocking network round trip, a flash of invisible or swapped text, and a privacy leak of your visitor's IP to Google. next/font removes all three by turning fonts into a build-time asset.

9 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A team loads the same Google Font by calling `Inter({...})` separately in two different component files instead of sharing one exported instance. What's the actual consequence?

The font gets hosted as two separate instances — each call to the loader function creates its own instance rather than reusing oneNothing — Next.js automatically deduplicates identical font loader calls across files at build timeThe second call throws a build error since a font can only be loaded once per application

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Font Optimization with next/font

What interviewers actually ask about this, and what a strong answer has to cover.

Your team currently loads a custom Google Font with a <link> tag in the HTML head. A teammate proposes switching to next/font/google and says it will "make fonts load faster." Is that the right justification, and what would you actually tell them changes?

A strong answer covers

Identifies that next/font self-hosts the font by downloading it at build time, so the browser never makes a runtime request to Google Fonts
Explains this removes both a privacy leak (visitor IP sent to Google) and a network round trip, distinct from just 'faster'
Connects it to layout shift specifically — build-time knowledge of font metrics lets Next.js size an automatic fallback font to avoid reflow
Recognizes 'faster' alone undersells it — the concrete mechanisms are self-hosting and layout-shift prevention, not a vague speed claim

Likely follow-ups

If the team needs two different typefaces on the same page, what's the actual cost of adding the second one, and is there a point where that stops being a good tradeoff?
Where in the app would you call the font loader function to get it preloaded on every route versus only a subset?

Practice these with the AI interviewer →

The plain-language idea

next/font downloads and self-hosts font files as part of your build, instead of asking the browser to fetch them from Google Fonts (or another CDN) at request time. For next/font/google, the CSS and font files are downloaded once at build time and served from your own app alongside your other static assets — no request is ever sent to Google by the browser, which removes both the privacy leak and the extra DNS/connection round trip a <link href="fonts.googleapis.com"> tag costs you. next/font/local does the same self-hosting for a font file you already own, no network fetch involved at all, ever.

The other half of the win is layout shift. Because the font loader knows the font's metrics at build time, Next.js can inject a size-adjusted fallback font automatically, so the page doesn't visibly reflow once the real font finishes loading — this is what "no layout shift" from font loading actually means in practice, not just "the font loads fast."

See it in a real thing: a shared font across the whole app

// app/fonts.ts
import { Inter, Roboto_Mono } from "next/font/google";

export const inter = Inter({
  subsets: ["latin"],
  display: "swap",
  variable: "--font-inter",
});

export const robotoMono = Roboto_Mono({
  subsets: ["latin"],
  display: "swap",
  variable: "--font-roboto-mono",
});

// app/layout.tsx
import { inter, robotoMono } from "./fonts";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={`${inter.variable} ${robotoMono.variable}`}>
      <body>{children}</body>
    </html>
  );
}

/* app/globals.css */
@theme inline {
  --font-sans: var(--font-inter);
  --font-mono: var(--font-roboto-mono);
}

Calling Inter(...) doesn't return a font, it returns an object with a className, a style, and here a variable — the CSS custom property name Next.js will declare and fill with the resolved font-family stack (real font, plus the auto-generated size-adjusted fallback). Applying inter.variable to <html> makes --font-inter available everywhere below it, which is what the Tailwind @theme inline block wires into font-sans. This variable approach is the one worth defaulting to over className: it lets you keep font selection in your CSS/Tailwind config rather than threading a className prop through every component that needs a specific typeface.

What people usually miss

Watch out

"Self-hosted" doesn't mean you manage font files yourself for Google Fonts. Next.js still downloads them from Google's CDN — but only once, at build time, on your machine/CI, never from your visitor's browser. The distinction is who makes the request and when, not whether Google is involved at all.
A font call isn't automatically global. A font loaded inside a specific page is only preloaded on that page's route; loaded inside a layout, it's preloaded on every route under that layout; only a root-layout font call is preloaded everywhere. Calling the same Google Fonts function in two different files creates two separate hosted instances — load it once in a shared file and import the result.
Multi-word Google Font names use an underscore on import, not a space: Roboto_Mono, not RobotoMono or "Roboto Mono". Forgetting this is a silent import failure, not a helpful error.
display defaults to 'swap', not 'auto' or 'block' — text renders immediately in a fallback font and swaps to the real one once it loads, rather than staying invisible while waiting. This is usually what you want, but it's worth knowing it's the framework's choice, not a browser default.
Loading more than one or two fonts is a real performance cost, not a style choice with no downside — every additional font family is another file the client has to fetch and render, even with self-hosting removing the network-waterfall problem.

Why this matters in interviews

"Why would you use next/font instead of a Google Fonts <link> tag?" tests whether a candidate can name the actual mechanisms — self-hosting removing a runtime network request, and build-time metrics removing layout shift — rather than a vague "it's faster" that doesn't survive a follow-up question.