DEV Community: Zerrin Arslan

Adding custom fonts to a Next.js app without the layout shift

Zerrin Arslan — Mon, 15 Jun 2026 17:38:38 +0000

If you've used Next.js in the last couple of years you've probably reached for next/font. It's genuinely great — but I still see custom fonts done in ways that tank the Lighthouse score or make the page jump around on load. Here's how I actually wire up fonts in a Next.js app now, and the one thing that quietly fixes most of the layout shift.

Google fonts: `next/font/google` already self-hosts

First, a thing a lot of people miss: next/font/google doesn't load anything from Google's servers at runtime. At build time Next downloads the font files and serves them from your own origin. So you get the self-hosting win (no third-party request on the critical path) for free:

import { Inter } from "next/font/google";

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

export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

That subsets: ["latin"] line matters — it subsets the file so you're not shipping glyphs for languages you don't use.

Custom / paid fonts: `next/font/local`

For a font that isn't on Google Fonts — a brand font, a freebie you downloaded, whatever — use next/font/local and point it at a WOFF2 in your project:

import localFont from "next/font/local";

const display = localFont({
  src: [
    { path: "./fonts/MyFont-Regular.woff2", weight: "400", style: "normal" },
    { path: "./fonts/MyFont-Bold.woff2",    weight: "700", style: "normal" },
  ],
  display: "swap",
  variable: "--font-display",
});

Then expose it as a CSS variable and use it wherever:

<html className={display.variable}>

.heading { font-family: var(--font-display), sans-serif; }

If your font is a .ttf/.otf, convert it to WOFF2 first — smaller and supported everywhere. I usually just drop it into FontBoxDL's webfont generator (browser-based, no install) and grab the WOFF2 back. And if you're still hunting for the font itself, the free library has a pile of them.

The thing that actually fixes layout shift

Here's the part people skip. Even with display: swap, when the real font swaps in it usually has different metrics than the fallback — so text reflows and your CLS spikes. next/font can fix this automatically if you give it a fallback to match against:

const display = localFont({
  src: "./fonts/MyFont-Regular.woff2",
  display: "swap",
  fallback: ["system-ui", "arial"],
  adjustFontFallback: "Arial", // generates a size-adjusted @font-face for the fallback
});

adjustFontFallback makes Next emit a fallback @font-face with size-adjust/ascent-override tuned so the fallback occupies almost exactly the same space as your real font. The swap becomes nearly invisible. This one prop has done more for my CLS numbers than anything else.

Quick gotchas

Don't import a font inside a component that re-renders. Declare it at module scope (top of the file), once. Importing it in the render path defeats the optimization.
variable vs className: use className if it's your single global font; use variable when you want multiple fonts available as CSS custom properties.
Preload is automatic for fonts used on the route — you don't need a manual <link rel="preload"> like you would in a plain HTML setup.

TL... actually, no TL;DR

Use next/font/google for Google fonts (it self-hosts), next/font/local for everything else, ship WOFF2, and set adjustFontFallback so the swap doesn't shove your layout around. Takes ten minutes and your Core Web Vitals will thank you.

What's your go-to for custom fonts in Next — next/font/local, or do you still hand-roll the @font-face?

I stopped loading fonts from Google's CDN — here's the self-hosting setup that stuck

Zerrin Arslan — Mon, 15 Jun 2026 16:42:33 +0000

For years I just dropped the Google Fonts <link> in my <head> and moved on. One line, done, who cares. Right?

Then I was staring at a Lighthouse report for a landing page that felt sluggish, and there it was in the waterfall: a render-blocking hop to fonts.googleapis.com, then a second one to fonts.gstatic.com for the actual file. Two extra connections — DNS lookup, TLS handshake, the whole dance — before a single character painted. On my laptop? Invisible. On a mid-range Android over flaky mobile data? Very visible.

So I bit the bullet and self-hosted. Took an afternoon, and I've done it on every project since. Here's the setup I've landed on after a bunch of trial and error.

Get a WOFF2 (and only WOFF2)

WOFF2 is supported literally everywhere now and it's ~30% smaller than the old WOFF. You don't need the .ttf, .eot, .svg fallback zoo from 2014 anymore. Just ship WOFF2.

If you've got a .ttf/.otf, convert it with fonttools:

pip install fonttools brotli
fonttools ttLib.woff2 compress MyFont.ttf   # -> MyFont.woff2

Honestly I got tired of doing the CLI thing for one-off fonts, so I ended up building a little browser tool for it — FontBoxDL's webfont generator — drop a TTF/OTF in, get WOFF2 + a @font-face block back, no install. Use whatever's less friction for you.

The @font-face block

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

The line that matters most here is font-display: swap. It tells the browser "show the fallback text immediately, swap in the real font when it arrives." Without it you get FOIT — invisible text while the font loads — which is a worse experience than a quick font flash, basically every time.

Preload the one font that matters

Drop this in your <head>:

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

Two things people get wrong here, me included:

Don't preload everything. Preload only the font(s) you actually use above the fold. If you preload six weights, you've just created a different bottleneck.
Don't forget crossorigin. I once left it off and spent a solid 20 minutes confused about why the font was being downloaded twice. Fonts are always fetched in CORS mode, so the preload has to match or the browser throws your preloaded copy away.

Subset if you care about bytes

A full font ships thousands of glyphs you will never render. If your site is English/Latin, subsetting can knock off 70%+:

pyftsubset MyFont.ttf \
  --unicodes="U+0000-00FF" \
  --flavor=woff2 \
  --output-file=myfont.subset.woff2

I don't always bother for a single light body font, but for display/heading fonts it's an easy win.

Cache it like it'll never change (because it won't)

Fingerprint the filename, then cache forever:

Cache-Control: public, max-age=31536000, immutable

Don't skip the fallback stack

Even with swap, give it a real fallback so the first paint looks intentional and the layout doesn't lurch when the swap happens:

body {
  font-family: "MyFont", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
}

That's the whole thing. Convert → @font-face with swap → preload the critical one (with crossorigin!) → cache hard. It's maybe an hour of work and you get a real LCP/CLS improvement plus one fewer third party in your critical path.

Anyone still on the Google CDN <link> for production — what's keeping you there? Genuinely curious if there's a case I'm missing.