Web Font Loading Strategies

The plain-language idea

A custom web font has to download before the browser can render text in it. While it's loading, the CSS property font-display controls what the browser does with any text that's ready to paint but whose font isn't in yet. Three values matter, and none of them is strictly better than the others:

• swap — show a fallback font immediately, then swap to the real font the moment it loads. Text is visible fast, but if the fallback and the real font have different metrics (character widths, line height), the swap can cause a reflow: text reflows into different line breaks, other content shifts down. This is a direct instance of the layout-shift problem the CLS-diagnosis material covers, just with a font swap as the specific trigger instead of an unsized image.
• block — hide the text for a short period (typically capped around 3 seconds by the browser) waiting for the real font, then show it. This avoids the visual swap entirely, but delays when the reader can see any text at all. Genuinely worse for perceived load speed, genuinely better for avoiding a jarring swap — a real tradeoff, not a strictly-worse option.
• optional — use the custom font only if it's already cached or loads near-instantly; otherwise, stick with the fallback for this page view and don't swap in the custom font later even once it finishes loading. This is the safest choice for avoiding both a flash of unstyled text and a layout shift, at the real cost of sometimes never showing the custom font on a given visit.

See it in a real thing: the same heading under three settings

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
  font-display: swap; /* fast text, risks a metrics-mismatch reflow */
}

/* A genuinely critical, above-the-fold font is worth preloading directly: */

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

Changing only the font-display value changes the tradeoff, not the download itself: swap gets text on screen fastest but risks the reflow; block avoids the reflow's visual jank at the cost of a blank-text delay; optional avoids both by sometimes not using the custom font at all. The preload hint (from the resource-hints lesson) is a separate, complementary decision — it makes the font arrive sooner, which shrinks the window during which any of these tradeoffs matter, but it doesn't change which tradeoff you're making.

What people usually miss

Watch out

• swap isn't a free win — it trades a visual flash for a possible reflow-driven layout shift. Choosing swap without checking whether the fallback and real font have similar metrics is how a font-loading choice becomes a CLS regression.
• block isn't "safer" by default — it delays perceived load. A page using block can genuinely feel slower to a real user even though no metric moved, because there's a window where the page shows no text at all.
• optional sometimes just never shows your custom font on a given page view, and that's the intended behavior, not a bug — it prioritizes stability over brand consistency for that visit.
• Preloading a font and choosing its font-display value are two separate decisions that both matter. Preloading shrinks how long the font takes to arrive; font-display decides what happens with text while it's still arriving. Doing one without the other leaves half the problem unaddressed.
• Only preload fonts that are actually used above the fold on first paint. Preloading every font weight/style in a family competes for bandwidth the same way over-preloading images does, covered in the resource-hints lesson.

Why this matters in interviews

"Why does the page's text jump around right after it loads?" is a real diagnostic question, and tracing it to a font-display: swap metrics mismatch (rather than just an unsized image) shows you understand CLS has more than one common cause.