Should you really prioritize FOUT over FOIT to enhance your Core Web Vitals?

What distinguishes FOUT from FOIT?

FOIT (Flash of Invisible Text) refers to the moment when your browser completely hides the text while waiting for the custom web font to load. During this time, the user sees a blank page or empty areas where the text content should appear.

FOUT (Flash of Unstyled Text) immediately displays the text using a fallback system font, then swaps to the custom font once it has loaded. The visitor can read the content within the first milliseconds, even if the final visual rendering is not yet optimal.

Why is Google promoting this approach now?

The answer lies in two acronyms: LCP and CLS. FOIT delays the text display, which directly degrades your Largest Contentful Paint if your main content is textual. Many e-commerce or editorial sites see their LCP explode due to custom fonts that take 2-3 seconds to load.

While FOUT does create a slight visual flash during the font swap, this micro-change is significantly less penalizing than a prolonged blank screen. Google has clearly calculated: readable text immediately is better than a perfect but delayed rendering.

How can I technically induce FOUT instead of FOIT?

Modern browsers have evolved in how they handle FOIT. Some, like Chrome, enforce a maximum 3-second timeout before displaying text with a fallback font. Others, like Safari, use an unlimited timeout, which can create disastrous situations.

To enforce consistent FOUT behavior, you need to use the CSS property font-display with the value swap or fallback. The swap value shows the system text immediately and then swaps as soon as the custom font arrives. The fallback value imposes a very short swap window (100ms) and then blocks the swap permanently if the font has not arrived.

• font-display: swap ensures that the text is always visible, at the cost of a potential late flash
• font-display: fallback limits the risk of CLS by blocking late swaps after about 3 seconds
• font-display: optional lets the browser decide based on network conditions, which is the most performing approach but less predictable
• The old practice font-display: block results in exactly the FOIT that Google now advises against
• Always declare consistent fallback fonts in your font stack (size, weight, spacing similar) to minimize CLS during the swap

Is this directive really new or just a reminder?

Let's be honest: Google has been repeating this advice since the introduction of font-display in 2016. What has changed is the context of Core Web Vitals that transforms a UX recommendation into a measurable ranking criterion. Previously, optimizing font loading was a nice-to-have for demanding sites.

Today, with the growing weight of CWV in the algorithm, ignoring FOIT can practically cost you positions. I observe on the ground that sites shifting from block to swap regularly gain 0.5 to 1 second on their LCP, moving them from orange to green in PageSpeed Insights.

In what cases does this rule become problematic?

Google's recommendation assumes that textual content takes precedence over visual identity. However, some luxury sites or creative agencies have such distinctive fonts that FOUT creates visually unacceptable dissonance for their brand.

In these cases, you have two options: either aggressively preload your critical fonts using <link rel="preload"> to reduce the delay to 200-300ms and make the FOIT almost invisible, or accept an average CWV score by using font-display: block. [To be verified]: Google has never clarified whether a poor LCP caused by branding choices could be compensated by other signals.

Doesn't FOUT actually generate CLS during the swap?

Absolutely, and that's the cunning trap of this recommendation. Swapping from Arial to a custom font with different metrics results in a reflow of the text that can shift your entire layout. I've seen sites go from 0.05 to 0.18 CLS just because of a poorly managed font swap.

The solution lies in using size-adjust, ascent-override, and descent-override in your @font-face to match the dimensions of your custom font exactly with those of the system fallback. Google Fonts now provides these values calculated automatically. Without this adjustment, you're trading an LCP issue for a CLS issue, which solves nothing.

How can I audit my current fonts and detect FOIT?

Open Chrome DevTools, go to the Network tab, filter on Font, and refresh your page in throttling Fast 3G. Observe if your headers and paragraphs remain empty while downloading the .woff2 files. If they do, you are experiencing FOIT.

Another method: inspect your @font-face declarations in the CSS. If you see no font-display property, browsers apply their default behavior, which varies. Chrome does FOIT with a 3s timeout, Safari does unlimited FOIT. You have no control, thus you suffer.

What value of font-display should I choose according to my context?

font-display: swap suits 80% of editorial, e-commerce, and service sites. You guarantee immediate readability and accept a micro-visual flash. It's the choice most aligned with Google's directive.

font-display: fallback works better for sites where visual consistency matters greatly but where you cannot preload all fonts. The swap gets blocked after the short window, avoiding late visual changes that disrupt users already reading.

Should I treat font icons differently from text fonts?

Yes, and this is a commonly overlooked point. Icon fonts (Font Awesome, Material Icons) create catastrophic FOIT: your navigation icons, CTA buttons, rating stars completely disappear. Use font-display: block only for these fonts and preload them as a high priority.

Better yet, migrate to SVG inline or sprites for critical icons. Icon fonts are a technical debt that unnecessarily burdens your CWV. I observe that replacing Font Awesome with optimized SVGs saves 200-400ms of LCP on icon-rich pages.

• Audit all @font-face declarations and add font-display: swap (or fallback depending on context)
• Calculate size-adjust metrics for each custom font to match the system fallback
• Preload with <link rel="preload"> only the 1-2 critical fonts used above-the-fold
• Test in 3G network throttling the actual swap behavior and measure the CLS impact
• Consider limiting the number of weights and styles loaded (regular + bold is often sufficient)
• Migrate critical icon fonts to inline SVG to eliminate this FOIT vector