When should you use CSS font metric overrides to prevent layout shift from late web font loads?

Use CSS font metric overrides after you have already reduced font delay and chosen a sensible font-display policy, but text still shifts when the real font replaces the fallback. They are best for brand text fonts where fallback rendering is acceptable yet line wraps or line-box height still move visible content. They are not your first fix, and they are fragile for mixed scripts, icon fonts, and some variable-font setups.

Why does late font activation move layout even when font-display is already set?

A fallback font and the final web font rarely occupy the same space. When the web font arrives, text can change width, wrap onto different lines, or alter line-box height. That is exactly the failure mode metric overrides target.

The first boundary is ordering: first make the real font arrive earlier, then decide whether swap behavior is acceptable, and only then tune fallback metrics. The web.dev font best practices guide emphasizes earlier discovery and delivery, including preload, critical @font-face discovery, and subsetting. If preload, caching, self-hosting, or smaller subsets remove the late swap, overrides may be unnecessary.

When are metric overrides the right tool?

Use them when all three are true:

• You intentionally allow fallback text to render first.
• The remaining issue is visible movement, not unreadable text.
• You can commit to testing and maintaining a specific fallback pair.

A practical checklist:

1. Reduce delay first: subset fonts, preload the exact file, and avoid late stylesheet discovery.
2. Choose behavior: font-display: optional can be better if a later swap is worse than staying on fallback.
3. Add overrides only if CLS or visible wrapping still regresses.

How do size-adjust and the metric overrides actually work?

On the fallback face, size-adjust scales glyph outlines and metrics. MDN says it applies to “glyph outlines and metrics associated with this font,” including advances, so it can reduce wrap changes as well as perceived size differences (MDN size-adjust).

The other three descriptors target line-box behavior for that fallback face:

• ascent-override changes height above the baseline.
• descent-override changes height below the baseline.
• line-gap-override changes the recommended external leading.

Worked example, with a local fallback tuned to a brand font:

/* Prerequisite: a measured fallback pair, for example Brand Sans -> Arial. */
@font-face {
  font-family: "Brand Sans Fallback";
  src: local("Arial");
  size-adjust: 97%;
  ascent-override: 92%;
  descent-override: 24%;
  line-gap-override: 0%;
}

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans-regular.woff2") format("woff2");
  font-display: swap;
}

.hero-title {
  font-family: "Brand Sans", "Brand Sans Fallback", sans-serif;
}

The goal is not visual perfection in isolation. The goal is that fallback and final text occupy nearly the same width and vertical space in real components.

How should you measure whether overrides helped?

Check the page in DevTools with cache disabled and slow network emulation. Look for changed wraps, truncation, button growth, and movement above the fold. Then compare CLS before and after in the field or lab. If the swap still changes line breaks, size-adjust is still off; if blocks jump vertically, revisit ascent, descent, and line-gap.

Where do metric overrides fail or backfire?

MDN marks ascent-override, descent-override, and line-gap-override as limited-availability features, so support is less uniform than size-adjust (MDN ascent-override). They also get brittle when one fallback must cover multiple scripts, when user font substitution changes the local face, or when a variable font changes dimensions across axes. Avoid this approach for icon fonts entirely: spacing may line up while glyph meaning does not. Be careful with fixed-height UI, clamped headlines, or tightly tuned line-height; matching one viewport can create clipping elsewhere.

Follow-up Q&A?

Should I use overrides with font-display: optional? Usually no. If you prefer no late swap, optional already avoids much of the problem.

Can overrides eliminate all font-related CLS? No. They can reduce differences, but rendering varies by browser, platform, script, and user font availability.

Your next step: pick one high-traffic text component, test a specific fallback pair under throttled loading, and ship overrides only if they measurably reduce visible movement without clipping.

Reviewed: 2026-09-05.