Font Loading and font-display

## Why the browser needs a policy at all When a stylesheet declares a family with `@font-face`, the glyph outlines live in a separate file that must be fetched over the network. Layout can be ready to paint a paragraph long before that file lands — on a fast connection the gap is tens of milliseconds, on a congested mobile connection it can be several seconds. The browser has to put *something* on the screen during that gap, and `font-display` is how an author says which compromise they prefer. ## FOIT: flash of invisible text With FOIT the browser lays the text out but paints no glyphs. The box is the right size, the surrounding layout is settled, and the reader sees an empty region where the words should be. Nothing is broken — the text simply has not been drawn yet. Browsers do not do this forever: after a timeout they give up and paint a fallback face so the page is not permanently unreadable. FOIT trades *readability* for *visual stability*: the reader waits, but never sees the text change shape. ## FOUT: flash of unstyled text With FOUT the browser paints straight away using the next family in the `font-family` list, or the generic default if none matches, and then repaints in the web font once it arrives. The content is readable from the first paint. The cost is the visible swap: glyph shapes change mid-read, and because two faces almost never share identical metrics — width per character, x-height, line height — the text can reflow when the swap happens. FOUT trades visual stability for readability. ## Where the descriptor goes `font-display` is a *descriptor* inside `@font-face`, not a property you can set on a selector: ```css @font-face { font-family: "Inter"; src: url("/fonts/inter-400.woff2") format("woff2"); font-weight: 400; font-style: normal; font-display: swap; } body { font-family: "Inter", system-ui, sans-serif; } ``` It applies per face, so a family shipped as four separate weight files needs the descriptor in all four `@font-face` blocks. Writing `font-display: swap` in a normal rule such as `body { … }` does nothing at all — a common review finding. ## The five values at a glance - `auto` — leave it to the browser. In practice mainstream browsers treat this like `block`, so an undeclared `font-display` gives you FOIT. - `block` — hide the text briefly, then swap whenever the font arrives. - `swap` — paint the fallback almost immediately and swap whenever the font arrives. The straightforward FOUT choice. - `fallback` — paint the fallback almost immediately, but only accept the swap within a short window; a very late font is ignored for this page load. - `optional` — paint the fallback almost immediately and never swap on this load; the file is still cached for later navigations. ## What font-display does not do It does not make the font arrive faster and it does not change *when* the request starts — the browser still fetches the file only after style resolution finds an element that actually uses the family. It has no effect on families already installed on the device, because there is nothing to download. And it does not remove the restyle that FOUT causes: `swap` is a decision to *show* the swap rather than hide it. If the real problem is that the font is discovered late, changing the descriptor only changes which bad frame the user sees. ## Which one is usually right For body copy, most teams pick FOUT: unreadable text is a worse failure than restyled text, and a reader who has already started the sentence is not blocked. For an icon font the logic inverts — a fallback family has no matching glyphs, so `swap` renders letters or tofu boxes where icons should be, and briefly showing nothing is the lesser evil. The judgment depends on how different the fallback looks and how much of the page the face covers.