FrontendHaltWeb font loading performance
Control the flash of invisible or unstyled text and its layout-shift cost with font-display, preload, and fallback metrics.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain web font loading performance in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
Custom web fonts arrive after HTML and CSS. Until a font loads, text is either invisible or shown in a fallback that then swaps — both are visible glitches. Font strategy is about controlling that gap and its layout impact.
One-line definition: Control the flash of invisible or unstyled text and its layout-shift cost with font-display, preload, and fallback metrics.
02Mental model
font-display controls the gap: swap shows fallback then swaps (readable immediately, layout shift on swap); optional uses fallback and only swaps on a future load (no shift, font may not appear first visit). Preloading the font removes a round trip. The swap's layout-shift cost is reduced by matching the fallback's metrics to the web font with size-adjust and ascent/descent overrides. Subsetting and WOFF2 cut file size; a variable font replaces many files with one.
03Step by step
- Self-host the font as WOFF2 and preload the specific weights used above the fold.
- Choose font-display deliberately — swap for body text, optional if you can't tolerate any shift.
- Define an @font-face fallback with size-adjust and ascent-override tuned to the web font's metrics.
- Subset the font to the character ranges actually used to shrink the file.
- Prefer one variable font over separate files when several weights are used.
- Verify with the performance panel that the font swap doesn't cause a measurable layout shift.
04Working example
@font-face { font-family: "Inter"; src: url("/fonts/inter.woff2") format("woff2"); font-weight: 100 900; font-display: swap;}@font-face { font-family: "Inter Fallback"; src: local("Arial"); size-adjust: 107%; ascent-override: 90%;}The variable Inter file covers every weight in one download, and font-display: swap keeps text readable in the fallback while it loads. The tuned fallback face makes Arial occupy nearly the same space as Inter, so when the real font swaps in, line lengths and heights barely change and layout shift stays near zero.
05Where it is used
- Keeping text readable during load without a flash of invisible text
- Minimizing layout shift caused by the fallback-to-webfont swap
- Cutting font bytes with WOFF2, subsetting, and variable fonts
- Removing a render round-trip by preloading critical font files
06Common mistakes
- Loading fonts from a third-party CSS URL, which adds a connection and a CSS round trip before the font is even requested
- font-display: block or default causing invisible text for up to 3 seconds on slow connections
- Not matching fallback metrics, so every page visibly reflows when the web font arrives
- Preloading many weights just in case, competing with more critical resources for bandwidth
07Interview answer
Name FOIT vs FOUT and which font-display value produces each. Know that the swap's layout-shift cost is fixable with fallback metric overrides, and that self-hosting plus preload beats a third-party font CSS.
Why can loading a font via a third-party stylesheet URL be slower than self-hosting the same font?
The browser must first download and parse that external stylesheet — a separate connection and round trip — before it even discovers the font file URL and can request it, whereas a self-hosted font declared in the site's own CSS and preloaded can start downloading much earlier.
DDConcept deep dives
Deep dive 1
The loading gap is unavoidable; the question is what fills it
Web fonts arrive after HTML and CSS, so there is always a window before the custom font is ready. font-display decides what the user sees in that window: block briefly hides text (FOIT), swap shows a fallback and swaps when the font loads (FOUT, always readable), and optional prioritizes stability by only swapping within a short window. For body content, swap is usually right — readable text beats a blank layout.
- FOIT means invisible text; FOUT means a visible font swap and often a reflow.
- swap keeps content readable at the cost of a swap; optional avoids the swap at the cost of maybe not showing the font on first visit.
- The default (auto) behaves close to block in most browsers — usually not what you want.
Deep dive 2
The swap's layout shift is fixable with fallback metrics
When the fallback font and the web font have different character widths and line heights, the moment the web font swaps in, text reflows — a visible jump scored as layout shift. Defining a fallback @font-face over a local system font with size-adjust, ascent-override, descent-override, and line-gap-override tuned to match the web font's metrics makes the fallback occupy nearly identical space, so the swap barely moves anything.
- Match the fallback's metrics to the web font, not the other way around.
- Tools can compute the override values from the two fonts' metrics.
- This is what makes font-display: swap safe to use without a CLS penalty.
Deep dive 3
Bytes and round trips: self-host, preload, subset, and consider variable
A third-party font stylesheet costs a connection and a CSS round trip before the font file is even requested; self-hosting collapses that and lets you preload the specific weights used above the fold so the download starts early. Subsetting to the character ranges actually used (often just Latin) cuts file size, and one variable font replaces many static weight files when several weights are used.
- Preload only the one or two above-the-fold weights — more just creates contention.
- WOFF2 plus subsetting is the baseline for size.
- Variable fonts win when you use several weights; a single-weight static file is smaller for one weight.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What are FOIT and FOUT?Open model answer
Model answer
Flash of Invisible Text: text is hidden while the web font loads, so the layout is there but blank. Flash of Unstyled Text: text renders immediately in a fallback font, then re-renders in the web font when it arrives, causing a visible swap and often a reflow.
Open question page →Intermediate · Conceptual · 1 min · Question 2What does each font-display value do?Open model answer
Model answer
block briefly hides then swaps (FOIT then FOUT). swap shows fallback immediately and swaps whenever the font loads (FOUT, text always readable). fallback and optional show fallback and only swap within a short window, with optional never swapping after it, prioritizing stability over the custom font on the first visit.
Open question page →Advanced · Conceptual · 1 min · Question 3How do you eliminate the layout shift caused by the fallback-to-webfont swap?Open model answer
Model answer
Define a fallback @font-face over a local system font with size-adjust, ascent-override, descent-override, and line-gap-override tuned so the fallback occupies almost the same space as the web font. When the swap happens, metrics barely change, so text doesn't reflow.
Open question page →Intermediate · Conceptual · 1 min · Question 4Why is preloading a web font effective?Open model answer
Model answer
Fonts are normally discovered late, only when the browser parses the CSS rule that references them, which is already several steps into loading. A preload link starts the font download near the start of the page load, removing a serial round trip from the critical path.
Open question page →Intermediate · Conceptual · 1 min · Question 5What's the downside of loading fonts from a third-party font service's stylesheet?Open model answer
Model answer
The browser must connect to that origin, download and parse its CSS, and only then discover and request the actual font files from possibly another origin — multiple round trips before a single glyph is available. Self-hosting collapses that to one preloadable request.
Open question page →Intermediate · Conceptual · 1 min · Question 6How does subsetting reduce font size?Open model answer
Model answer
A full font file includes glyphs for many scripts and many characters most sites never use. Subsetting strips it to the character ranges actually needed — often just Latin — which can cut the file substantially. unicode-range on @font-face lets the browser only download subsets a page uses.
Open question page →Advanced · Conceptual · 1 min · Question 7When does a variable font help or hurt performance?Open model answer
Model answer
It helps when a site uses several weights or widths, since one variable file is smaller than many static files and covers the whole range. It can hurt if the site uses only one weight, since a single-weight static file is smaller than the full variable axis.
Open question page →Intermediate · Conceptual · 1 min · Question 8Should you preload every weight the site uses?Open model answer
Model answer
No — preload only the one or two weights needed for above-the-fold text. Preloading many fonts makes them all compete with each other and with other critical resources for early bandwidth, delaying first paint.
Open question page →Advanced · Conceptual · 1 min · Question 9How do you verify a font strategy is actually working?Open model answer
Model answer
Check the performance panel for when the font request starts and finishes relative to first paint, look for a layout shift entry at the swap moment, and test on a throttled connection where FOIT and reflow are most visible. Field CLS and render metrics confirm it at scale.
Open question page →Intermediate · Conceptual · 1 min · Question 10What is the 'font stack' fallback and why does the first fallback choice matter?Open model answer
Model answer
It's the ordered list of families in font-family. The first available fallback is what users see until the web font loads and, with optional, possibly permanently, so it should be a system font whose metrics are close to the web font to minimize the visual jump.
Open question page →SCScenario questions
Scenario 1
A content site loads two fonts (a serif for headings, a sans for body) from a third-party font CDN. Lighthouse flags render-blocking font CSS, a 2-second FOIT on slow connections, and layout shift when the fonts arrive.
- Self-host both fonts as WOFF2 in the site's own assets.
- Preload the body weight and the primary heading weight only.
- Set font-display: swap so text is readable during load.
- Add tuned fallback @font-face faces with metric overrides for each.
- Subset both fonts to the character ranges the content actually uses.
Reveal worked answer
The third-party CDN is adding a connection and a CSS round trip before the fonts are even requested, so I'd self-host both as WOFF2 and preload the specific weights needed above the fold. font-display: swap removes the FOIT — text renders in a fallback immediately. The layout shift comes from the fallback and web font having different metrics, so I'd add fallback @font-face declarations with size-adjust and ascent-override tuned to match each font, which makes the swap nearly invisible. Subsetting to Latin then trims the bytes further.