Fixing Layout Shift Caused by Web Fonts

Why a font swap moves the page

Every font has its own proportions. Two typefaces set at 16 pixels can differ noticeably in how wide each letter is, how tall the lower-case letters are, and how much space sits above and below a line. The CSS font-size is the same, but the text that results is not.

So when the browser paints a paragraph in the fallback and then repaints it in the web font, three things can change at once:

• Line breaks. Wider letters push the last word of a line onto the next one. A paragraph that took five lines now takes six, and the block gets taller.
• Line height. If line-height is set to normal, the gap between lines comes from the font file itself (its ascent, descent and line gap values). Switching fonts changes the height of every line even when no words move.
• Inline widths. Buttons, navigation items and labels that size themselves to their text grow or shrink, which can wrap a menu onto a second row.

Any of these makes the text block change height, and whatever sits below it is pushed up or down. That movement is what the browser records as a layout shift. Because the body font is usually used in the header and the first paragraphs, the moving area tends to be large and near the top of the screen, which is exactly where CLS scoring hurts most.

Why it varies between visitors

The shift only happens if the font arrives after the first paint. Returning visitors who have the file cached, and people on fast connections, often never see it. Mobile users on a new visit do. That is why a quick desktop test can look clean while the Core Web Vitals report in Search Console shows a problem on mobile.

What each font-display value does to layout

The font-display descriptor inside @font-face controls what the browser shows while a font is downloading and whether it will swap later. Browsers use roughly the time windows below; exact timings are up to the browser.

optional is the most stable choice: if the font is not ready almost immediately, the page keeps the fallback for that visit. The trade-off is that a first-time visitor on a slow connection may never see your brand font on the first page they open. For body text that is usually acceptable. For a logo-style display font it may not be, and there swap with a tuned fallback is the better pairing.

Proving the font is the culprit

Text shifting is not always a font problem. A banner inserted above the paragraph moves text too. Before changing anything, confirm the timing lines up with the font download.

1. Record a load. In Chrome DevTools open the Performance panel, set network throttling to a slow 4G profile and CPU to a 4x slowdown, tick the option to disable the cache in the Network panel, and record a reload. Look at the Layout shifts track. Font-related shifts usually list headings, paragraphs or navigation items as the moved nodes.
2. Compare with the font arrival. In the same recording, find the font requests in the network track. If the shift lands in the same frame as a .woff2 file finishing, you have your answer.
3. Block the fonts. In the Network panel, right-click a font request and choose to block that URL, then reload. If the shift disappears when the font can never arrive, the swap is the cause.
4. Log the moment fonts finish. Paste this into the console before reloading to print when each face is ready, then compare with the shift times shown by the CLS Debugger.

document.fonts.addEventListener('loadingdone', (e) => {
  console.log(Math.round(performance.now()) + ' ms',
    e.fontfaces.map((f) => f.family + ' ' + f.weight));
});

If several fonts finish at different times, you may see several small shifts in a row: regular text first, then bold, then italic. Each one reflows the paragraphs that use it. That pattern is a strong hint to cut the number of files, which is the cheapest fix of all.

Making the fallback the same size

The most reliable fix keeps the swap but makes it harmless. You declare a second @font-face that points at a font already installed on the device, and use four descriptors to stretch it to the proportions of your web font:

• size-adjust scales the glyphs, so the average letter width matches and lines break in the same places.
• ascent-override and descent-override set the space above and below the baseline, so each line is the same height.
• line-gap-override sets any extra space the font adds between lines, usually to zero.

@font-face {
  font-family: 'Harbour Sans';
  src: url('/fonts/harbour-sans-var.woff2') format('woff2');
  font-weight: 300 800;
  font-display: swap;
}
@font-face {
  font-family: 'Harbour Sans Fallback';
  src: local('Arial');
  size-adjust: 104.2%;
  ascent-override: 93%;
  descent-override: 24%;
  line-gap-override: 0%;
}
body {
  font-family: 'Harbour Sans', 'Harbour Sans Fallback', sans-serif;
}

The numbers above are placeholders. The correct values come from the web font's own metrics (units per em, ascender, descender, line gap and average character width) compared with the fallback's. Do not guess them by eye. Tools such as Capsize publish metrics for common fonts and can calculate the overrides, Fontaine generates the fallback rules at build time, and the Next.js font loader does it automatically for Google and local fonts.

The Android problem

Arial is present on Windows, macOS and iOS but not on most Android phones, where the default sans-serif is Roboto. If your only fallback face uses local('Arial'), it fails on Android and the browser falls through to the generic family with no adjustments. Add a second fallback tuned for Roboto and list both:

font-family: 'Harbour Sans', 'Harbour Sans Fallback Arial',
             'Harbour Sans Fallback Roboto', sans-serif;

Serif designs need the same treatment against Times New Roman, and on Android against the system serif.

Getting fonts to arrive before first paint

If the font file is ready when the text is first painted, there is nothing to swap. Several changes help it win that race.

Fewer, smaller files

Every weight and style is normally a separate file. A site using regular, medium, semibold, bold and italic of two families may request ten files, each able to trigger its own reflow. A single variable font covering the weight range, or simply using two weights, removes most of them. Subsetting to the characters you actually use (for example Latin only for an English site) and serving WOFF2 keeps each file small.

Preload what the first screen needs

<link rel="preload" href="/fonts/harbour-sans-var.woff2"
      as="font" type="font/woff2" crossorigin>

The crossorigin attribute is required even when the font is on your own domain, because fonts are always fetched in anonymous CORS mode. Without it the browser downloads the file twice and the preload is wasted. Preload one or two files at most; preloading every weight competes with the main image and can make LCP worse.

Self-host rather than chain requests

Loading from a third-party font service means the browser must connect to one host for the stylesheet, read it, then connect to another host for the files. Hosting the WOFF2 files on your own domain, with long cache lifetimes, removes those round trips. If you keep a hosted service, add preconnect hints for both hosts. Check the service's licence before self-hosting commercial fonts.

Less obvious font shifts

• Icon fonts. Ligature-based icon sets show the icon's name as plain text, such as "shopping_cart", until the font arrives, then collapse it to one glyph. Give icon elements a fixed width, height and overflow: hidden, or better, switch to inline SVG icons that need no font at all.
• Class-based font loaders. Scripts that add a class such as fonts-loaded to the page and only then apply the web font cause a swap after JavaScript runs, which is later than a normal CSS swap. Replace them with plain @font-face rules.
• Synthetic bold and italic. If the bold file is missing, the browser fakes bold by thickening the regular glyphs. When the real bold file loads later, the widths change again. Load the weights you use, or use a variable font.
• Fit-to-width headlines. Scripts that measure text and resize it to fill a line run once with the fallback and again when the font arrives. Use CSS clamp() sizes instead.
• Fonts inside iframes and embeds. Widgets load their own fonts. Their shifts usually stay inside the widget, but if the widget sizes itself to its content it can resize the frame and move your page.

The fix, step by step

Keeping font shifts from returning

• Treat fonts as part of the design system. Agree a short list of families and weights, and ask for a reason before another is added.
• Keep fallback metrics with the font. Store the fallback @font-face rules in the same file as the web font so a font change prompts a metrics update.
• Avoid line-height: normal. A unitless value such as 1.5 fixes line spacing regardless of which font is showing, which removes one source of height change entirely.
• Check new plugins and themes. Themes, page builders and widgets often add their own font requests. Look at the Network panel after installing anything.
• Test first visits. Include a cold-cache, throttled mobile run in your release checks, because that is the only situation in which font shifts show up.

For other causes on the same page, the CLS Debugger Fixes hub matches each symptom to its guide.