Font Loading Strategies: FOIT, FOUT & Beyond
Every custom font on your page introduces a loading race between the HTML content and the font file. How the browser handles that race determines whether users see invisible text, a jarring flash, or a smooth transition. This guide walks through every font loading strategy available to modern web developers, from basic CSS to the JavaScript Font Loading API.
Understanding FOIT: Flash of Invisible Text
FOIT is the browser's default behavior in most engines: when a web font is declared but not yet loaded, the browser renders the text node with an invisible placeholder that occupies the correct space. In Chrome and Edge, this invisibility period (called the 'block period') lasts up to 3 seconds before falling back to the system font. During those 3 seconds, users stare at a blank area where your heading or body text should be — this is catastrophic for perceived performance and directly increases your Time to Interactive because users cannot read or interact with content. Safari handles FOIT even more aggressively with no fixed timeout, potentially hiding text indefinitely on slow connections until the font loads or the request fails. FOIT is almost never the right choice for production: it sacrifices usability for visual consistency, and most users would rather see text in a fallback font than see nothing at all.
Understanding FOUT: Flash of Unstyled Text
FOUT occurs when the browser shows text in a fallback font first, then swaps to the web font once it finishes loading. This is triggered by setting font-display: swap in your @font-face rule. The advantage is that content is readable immediately — FCP is not blocked by font loading, and users can start reading within milliseconds. The downside is the visible reflow: the fallback font almost certainly has different metrics than the target font, so line lengths change, text blocks grow or shrink, and surrounding content shifts. This layout shift registers as CLS in Core Web Vitals and can easily push your score above the 0.1 'good' threshold if the metric differences between fonts are significant. Despite the shift, FOUT is generally the preferred baseline strategy for most web applications because it prioritizes content visibility over visual perfection. The reflow can be minimized dramatically with fallback font metric overrides, which are covered later in this guide.
The font-display CSS Property: All Values Explained
The font-display property offers five values that each define a different block-swap-failure timeline. The auto value defers to the browser's default strategy, which is typically FOIT — avoid it. The block value enforces a long invisible period (up to 3 seconds) followed by an infinite swap period — use this only for icon fonts where showing a wrong glyph would be confusing. The swap value has a minimal block period (~100ms) and an infinite swap period, meaning the font always eventually loads — best for brand-critical headings with preloading. The fallback value gives a ~100ms block period and a ~3-second swap period, after which it locks in whatever font is showing — a reasonable compromise for body text. The optional value has a ~100ms block period and zero swap period: if the font is not ready in time, the fallback is used for the entire page view and the web font is cached for subsequent navigations. This is the only value that guarantees zero CLS from font loading, making it the recommended choice for body text on performance-sensitive sites.
The Font Loading API: document.fonts
The CSS Font Loading API (document.fonts) gives you programmatic control over font loading and detection in JavaScript. The document.fonts.load('1em InterVariable') method returns a Promise that resolves when the specified font is available, letting you add a CSS class to trigger the swap only when ready. The document.fonts.ready property is a Promise that resolves when all queued font loads are complete, useful for delaying font-dependent measurements or canvas rendering. A common pattern is to add a 'fonts-loaded' class to the html element inside the .ready callback, then write CSS rules like .fonts-loaded body { font-family: 'Inter', sans-serif } so the swap is controlled by your code rather than the browser's default timing. The FontFaceSet interface also provides check(), which synchronously returns whether a font is currently available without triggering a load — useful for conditional logic like 'only apply this layout if the font is ready'. This API works in all modern browsers and is the foundation for advanced strategies like staged loading, where you load the regular weight first and defer italic and bold variants until after the initial render.
Progressive Font Loading: Critical CSS + Lazy Variants
Progressive font loading is a strategy where you prioritize a single font file for the initial render and defer everything else. In practice, this means preloading only the Regular (400) weight of your primary font, setting it to font-display: swap, and inlining its @font-face rule in critical CSS. The bold (700), italic, and any other variants load asynchronously after first paint — either via a deferred stylesheet or by dynamically injecting @font-face rules with JavaScript. For the initial render, the browser synthesizes bold and italic from the regular weight, which looks acceptable for the fraction of a second before the real files arrive. Zach Leatherman's 'Critical FOFT' (Flash of Faux Text) strategy formalizes this approach: load one optimized subset of the Roman font first, then use the Font Loading API to swap in the full family once all variants are cached. This technique reduces initial font payload from 4-6 files (200-400KB) to a single file (15-25KB subseted), dramatically improving LCP while still delivering full typographic richness within seconds of page load.
Fallback Font Matching: size-adjust & ascent-override for Zero Layout Shift
The CSS @font-face descriptors size-adjust, ascent-override, descent-override, and line-gap-override let you tune a fallback font's metrics to match your web font, eliminating the CLS caused by FOUT. For example, if your web font is Inter and your fallback is Arial, you can declare a local Arial @font-face with size-adjust: 107%, ascent-override: 90%, descent-override: 22%, and line-gap-override: 0% so that text blocks rendered in the adjusted Arial occupy nearly identical space to Inter. The next/font package in Next.js calculates these overrides automatically, and tools like Fontaine and capsize generate them for any font pair. In practice, well-tuned metric overrides reduce CLS from font swaps to under 0.001 — effectively invisible. The size-adjust descriptor scales the entire glyph em-square (affecting all metrics proportionally), while the individual override descriptors give you finer per-metric control. Combining these with font-display: swap gives you the best of both worlds: immediate text visibility, brand-correct typography once loaded, and zero measurable layout shift during the transition.
Try Font Finder Now
The fastest way to identify fonts on any website. Install the free Chrome extension and start inspecting typography in one click.