What Are FOUT and FOIT? (Web Font Loading)

When a page uses a custom web font, that font file has to download before the browser can paint text with it. Until it arrives, the browser has to decide what to do with any text that is supposed to use it: hide the text, or show it in a fallback font. Those two choices are the root of the two acronyms you will see in every web performance audit: FOUT and FOIT.

What FOIT means

FOIT stands for Flash of Invisible Text. The browser hides the text that depends on the web font until the font file finishes loading. The layout space is reserved, but the glyphs are not painted, so visitors see a blank gap where the words should be. If the font loads quickly, nobody notices. If the network is slow, the font request times out, or the file is large, readers can stare at invisible content for a noticeable stretch, which is bad for both experience and Core Web Vitals.

Historically this was the default behaviour in most browsers: they would hide the text for up to about three seconds, then fall back to a system font if the web font still had not arrived.

What FOUT means

FOUT stands for Flash of Unstyled Text. Instead of hiding the text, the browser renders it immediately in a fallback font (such as Arial or a generic sans-serif), then re-renders it in the web font once that file loads. The content is readable the whole time, but visitors may see a visible flicker or reflow as the typeface switches. If the fallback and the web font have very different widths or heights, the swap can shift surrounding layout.

FOUT is generally considered the lesser evil for body text, because readers can start reading straight away. The cost is a brief cosmetic flash and, potentially, a layout shift.

Controlling it with font-display

The CSS font-display descriptor, set inside an @font-face rule, lets you tell the browser which behaviour you want. It works by defining three phases: a block period (text invisible), a swap period (fallback shown, web font swapped in when ready), and a failure period (give up and keep the fallback).

• auto — leaves the choice to the browser. Most browsers default to behaviour similar to block, so this tends to produce FOIT.
• block — a short block period (around three seconds) then an infinite swap. This causes FOIT.
• swap — an extremely small block period and an infinite swap. The fallback appears instantly and is replaced whenever the font loads. This causes FOUT.
• fallback — a tiny block period and a short swap window. A compromise: a brief chance of invisible text, then fallback stays if the font is late.
• optional — a tiny block period and no swap. The browser may keep the fallback for the whole visit if the font is not ready, avoiding both flicker and layout shift.

A typical @font-face block looks like this:

@font-face { font-family: 'MyFont'; src: url('myfont.woff2') format('woff2'); font-display: swap; }

The three phases of a font load

It helps to picture what the browser is tracking the moment a font is requested. Every font-display value is really just a different setting for three windows of time:

• Block period. The browser waits for the font and renders affected text invisibly. If the font arrives, it is used; if the period ends first, the browser moves on. A long block period is what produces FOIT.
• Swap period. The browser shows a fallback font and will swap in the web font the instant it loads. A long (or infinite) swap period is what produces FOUT.
• Failure period. If the font still has not loaded, the browser gives up and treats it as a failed load, keeping the fallback for the rest of the page’s life.

So block is a long block plus infinite swap (FOIT then correct font), swap is almost no block plus infinite swap (immediate FOUT), fallback is a tiny block plus a short swap, and optional is a tiny block with effectively no swap. Once you see the three windows, the names stop being jargon.

Which value should you use?

For most text content, swap is the common recommendation: readers never wait on invisible text. If you are worried about layout shift when the font swaps in, pair it with the size-adjust, ascent-override and related descriptors, or a well-matched fallback stack, so the fallback occupies roughly the same space as the web font. For decorative or non-essential fonts, optional is a strong choice because it protects both perceived speed and layout stability. Reserve block for cases where showing the wrong font even briefly is genuinely unacceptable, such as an icon font where the fallback glyphs would be meaningless.

Two other techniques reduce the problem at the source: preloading the critical font file with <link rel="preload" as="font" crossorigin> so the download starts sooner, and self-hosting subset WOFF2 files so they are small and fast. The smaller and earlier your font arrives, the less either flash matters.

Why it matters beyond looks

The flashes are not only cosmetic. FOIT can delay when meaningful content becomes visible, hurting the Largest Contentful Paint metric if your headline or hero text depends on a slow web font. FOUT can cause Cumulative Layout Shift if the fallback and web font differ enough in width or height to push surrounding elements around when the swap happens. Both are things Google’s Core Web Vitals measure, so font loading strategy is a genuine SEO and user-experience concern, not just a detail for typographers. The practical goal is simple: get readable text on screen fast, and make any later swap as invisible as possible.

Frequently asked questions

Is FOUT or FOIT better?

For readable body text, FOUT is usually preferred because content is visible immediately. FOIT hides text, which can leave visitors looking at a blank space on slow connections. The main downside of FOUT is a brief flicker and possible layout shift when the font swaps in.

What is the default font-display behaviour?

If you do not set font-display, the value is auto, and most browsers treat that similarly to block. That means the default tends to produce FOIT, hiding text for a few seconds before falling back.

Does font-display: swap hurt Core Web Vitals?

It helps First Contentful Paint and Largest Contentful Paint because text paints immediately. It can contribute to Cumulative Layout Shift if the fallback and web font differ in size. Match the fallback with font metric override descriptors to minimise that shift.

How do I stop the font flicker entirely?

You cannot eliminate it for free, but you can make it invisible in practice: preload the font, serve a small subset WOFF2 file, use font-display: optional for non-critical fonts, and tune fallback metrics so the swap does not move anything. Fast fonts simply do not flash long enough to notice.

Do system fonts have FOUT or FOIT?

No. System font stacks (for example system-ui, sans-serif) use fonts already installed on the device, so there is nothing to download and no loading flash at all. That is one reason many teams use system fonts for UI text.