How would you decide which font-display value to ship for a product's primary text font, and what is the case for choosing optional?

## The choice is a product question, not a technical one Every `font-display` value is a trade between three things the reader experiences: how soon text is readable, whether the page changes under them while they read, and whether they ever see the brand face at all. No value gives all three. A principal-level answer names which one the product is willing to give up and why. ## Input one: what the face is for Body copy and headings carry meaning that a fallback can still convey. Latin text set in a system sans instead of the brand sans is *readable* — the reader loses aesthetics, not information. That is why a near-zero block period is the norm for text faces. An icon font is the opposite. Its code points map to symbols that no fallback family has, so painting the fallback produces letters or tofu boxes — visual noise that looks like a broken page and can be actively misleading when an icon means "delete". Here a short blocking period is defensible: a moment of nothing beats a moment of nonsense. The same logic covers symbol and math faces. ## Input two: how far the fallback is from the real face The visible cost of a swap scales with the difference between the two faces. If the fallback sets text at a similar width and weight, the swap is a subtle change of shape. If the brand face is much narrower or heavier, whole paragraphs re-wrap when it arrives, which is jarring for someone mid-sentence. The further apart the two faces are, the more attractive a policy that avoids swapping mid-read becomes. ## Input three: who the users actually are A team on office fibre sees every value behave identically. The decision belongs to the slower half of the real distribution — the visitors whose connections make the window matter at all — and to the share of visits that are repeat. High repeat traffic makes `optional` far cheaper than it sounds, because only the very first visit renders in the fallback and every subsequent one has the file cached. ## The case for optional `optional` says: paint the fallback almost immediately, and do not swap at all on this load. Two consequences follow. The upside is that the page is typographically final from its first paint. Nothing re-wraps under the reader's eyes, and the load has one text rendering rather than two. For a content product where people start reading at once, that stability is worth a great deal. The downside is honest and must be stated: some first-time visitors will complete their entire visit without seeing your typeface. If the brand face is the identity of the product — a marketing page whose whole job is the impression — that is a real loss, and `swap` is the better answer. What makes `optional` practical rather than theoretical is pairing it with a preload of the face. The block window is tiny, so with the file discovered only through the CSS chain the font essentially never wins it. Started early, alongside the stylesheet, a small woff2 on a decent connection frequently is ready in time, and the download that misses still populates the cache for the next navigation. Used this way, `optional` becomes "the brand face when we can get it there in time, and never a mid-read restyle when we cannot." ## Where fallback and block sit `fallback` is the hedge: readable straight away, a limited window in which a moderately slow font may still swap, and no swap at all if it is very late. It is a reasonable middle for a secondary face where the swap is mildly desirable but not worth allowing at any point in the load. `block`, and `auto` which behaves like it today, is only defensible when a fallback rendering would be wrong rather than merely plain. ## Make it a system, not a per-page decision At scale the failure mode is not choosing badly once; it is drift. New `@font-face` blocks appear without the descriptor and silently default to blocking behaviour, and one weight ends up with a different policy from another so headings and body text render out of step. The durable version of this answer is a documented default per font role, kept next to the font files, plus a check that fails when a face ships without an explicit value. ## Verify in the field Whichever value you pick, the lab will not tell you whether it worked — a fast machine with a warm cache resolves every font inside the block period. What you want from real users is the share of loads where the web font was actually applied and whether text-related instability went down after the change. That evidence is what turns the decision from a preference into a defensible call.