How Fonts Are Loaded and Why FOIT/FOUT Happens

Web fonts are not only crucial elements in branding and design but also affect the performance and visual stability of the whole website. The problems such as FOIT (Flash of Invisible Text) and FOUT (Flash of Unstyled Text) are directly connected to the fact that browsers do not handle the wholes font issues (discovery, download, and application during rendering) at once.

When a new page is opened by a browser, its first action is to decompose HTML and CSS to come up with the DOM and CSSOM. During this process, the browser will find any @font-face rules and begin the downloaded of related font files. Yet unlike images, fonts caused block of text rendering and the browser had to decide whether to pause for the font to come or to show text with a fallback right away.

FOIT: Flash of Invisible Text

FOIT happens when the browser:

• Hides text completely
• Waits for the custom font to load
• Renders text only after the font is available

This leads to blank text areas and poor perceived performance. Older browsers favored FOIT, which often confused users.

FOUT: Flash of Unstyled Text

FOUT occurs when the browser:

• Immediately renders text using a fallback system font
• Swaps to the custom font once it finishes loading

This approach shows content faster but may cause layout shifts due to font metric differences. Modern browsers generally prefer FOUT because it improves readability and user experience.

The Role of font-display

The browser’s behavior is controlled by the font-display property:

• block → forces FOIT
• swap → enables FOUT (most recommended)
• fallback → short block, then fallback
• optional → skips font on slow networks

Best Practices

• Use font-display: swap
• Prefer woff2 for smaller file sizes
• Preload critical fonts
• Limit font weights and styles
• Choose fallback fonts with similar metrics

Why This Matters

• Font loading impacts:
• First Contentful Paint (FCP)
• Cumulative Layout Shift (CLS)
• Perceived performance and UX