Set font-display: swap (or optional) on your web fonts so text stays visible while the font downloads, and preload the one font your first screen actually needs. Custom fonts are one of the sneakiest sources of two problems users hate: text that is invisible for a moment, and layout that jumps once the font arrives. Both come down to how the browser handles the gap between requesting a font and having it ready to paint.
The two failure modes: invisible text and layout shift
When a browser needs a web font it has not downloaded yet, it must decide what to do with the text in the meantime. By default many browsers hide the text entirely — a Flash of Invisible Text, or FOIT — leaving a blank space where your headline should be until the font file lands. On a slow connection that blank can last seconds, and to a user it reads as a broken or empty page.
The alternative is showing a fallback system font first and swapping in the custom font when it arrives — a Flash of Unstyled Text, or FOUT. That keeps content readable, but if the fallback and the custom font have different sizes and spacing, the swap shoves the layout around. That jump is Cumulative Layout Shift (CLS), one of the Core Web Vitals, and it frustrates users who lose their place or tap the wrong thing. Our Core Web Vitals guide explains why CLS matters and how it is scored.
How font-display controls the trade-off
The CSS font-display descriptor, set inside your @font-face rule, tells the browser exactly how to behave during that gap. The value swap shows fallback text immediately and swaps to the custom font whenever it loads — this eliminates invisible text and is the safe default for most sites. The value optional goes further: it gives the font a tiny window to load, and if it misses that window the browser simply keeps the fallback for that page view, which protects both speed and layout stability at the cost of occasionally not showing your brand font.
The values block and fallback sit in between, with block risking longer invisible-text periods. For content-first sites, swap or optional are almost always the right call. The key point is that leaving font-display unset means accepting whatever the browser defaults to — which is often the FOIT behavior you do not want.
Reduce the swap, not just survive it
Choosing a display strategy handles the symptom; you also want to shrink the gap itself. Preload the specific font file your above-the-fold content needs so the browser starts fetching it early instead of discovering it deep in the CSS. Preload only the critical font — usually one weight of your heading or body face — because preloading everything competes with your main content for bandwidth, a trap covered in our resource hints guide.
Then serve the font efficiently. Use modern WOFF2 files, subset them to the characters and languages you actually use, and self-host where practical so you avoid a separate connection to a font provider. To tame the layout shift specifically, tune the fallback so it closely matches the metrics of your web font — size-adjust and related descriptors let a system font stand in with nearly the same footprint, so the eventual swap barely moves anything. These are the same speed fundamentals as the rest of our website performance optimization advice.
Why this matters beyond aesthetics
Fonts feel like a design detail, but they sit on the critical rendering path, so they directly shape the metrics that search and AI systems use to judge page quality — and they shape whether a real user sticks around long enough to read you. A page that flashes blank or jumps as it loads erodes trust in a way no amount of good content fully recovers. Getting font loading right is low-effort, high-return polish.
Not sure whether your fonts are causing invisible text or layout shift? Run the CheckMy.site scanner to check your font-display settings, spot render-blocking font requests, and see how your loading strategy affects Core Web Vitals.