Discuss custom web font performance and loading strategies
Critical rendering path tradeoffs between speed and design fidelity. Strong answers match font-display to UX goals, combine preloading with subsetting, and quantify byte savings. Red flag: calling swap a free win while ignoring layout shift from reflow.
What's really being asked
This question tests whether you understand the critical rendering path and can reason about the tension between visual design and perceived performance. Interviewers want to see that you know custom fonts block rendering, increase payload, and cause layout instability if handled naively. At the senior level, they expect tradeoff analysis, not just reciting CSS properties.
The full answer
A strong response starts by naming the failure modes: FOIT where text stays invisible while the font loads, and FOUT where a fallback appears first then swaps. Next, it maps font-display strategies to user experience goals. Swap is best when readability matters more than exact layout, because it shows fallback text immediately then swaps. Optional is useful for stable layouts when the custom font is decorative. Block should generally be avoided. Then, discuss preloading: only preload the specific weight and unicode-range needed for above-the-fold content, because over-preloading steals bandwidth from render-critical resources. Mention subsetting to remove unused glyphs and compression via WOFF2. Finally, address layout stability. Mention the size-adjust descriptor, ascent-override, or fallback font calibration so the swap does not trigger large cumulative layout shift. If you know the numbers, note that a single Latin font file can drop from 200 kilobytes to under 30 kilobytes with aggressive subsetting.
The mistakes people make
The biggest red flag is treating font-display swap as a magic fix. Swap eliminates FOIT but guarantees FOUT, which causes layout shift if metrics differ between fallback and custom fonts. Another red flag is preloading every weight and style in the family; this hurts time to first byte and can delay more important resources. Saying subsetting is only for CJK fonts is also wrong, Latin sets still contain hundreds of unused glyphs.
What usually comes next
An interviewer might ask how you would measure the impact, so be ready to mention web font loading APIs, Lighthouse scores for CLS, or setting performance budgets in CI. They might also ask about variable fonts as an alternative to multiple static files, or how to handle third-party font services that do not support fine-grained control.
A concrete example
Imagine a marketing landing page using a 700-weight display font for the headline and 400-weight body text. The right strategy is to preload only the 700 headline font with a narrow unicode-range for the hero text, use font-display optional for the body font so it either loads instantly or stays in fallback, subset both files to Latin characters only, and declare a size-adjust fallback font to keep the headline from jumping when the swap occurs.
Interview question
Which strategy best balances rendering speed and layout stability for an above-the-fold custom headline font?
- a.Preload every weight in the family and use font-display swap to eliminate invisible text
- b.Use font-display optional so the headline only appears after the custom font loads successfully
- c.Subset to Latin glyphs, preload only the needed weight, and calibrate fallback metrics to reduce shiftCorrect
- d.Apply aggressive subsetting and font-display block to ensure the custom font always renders first
Why? this is the answer
This approach minimizes payload through subsetting, avoids bandwidth contention by preloading only the critical weight, and prevents layout shift by matching fallback metrics. The most tempting distractor advocates preloading every weight and relying on swap alone, which the card flags as a red flag because it delays render-critical resources and guarantees layout shift from uncalibrated fallbacks.
Just read this? Test yourself on what you have been reading.
- #fonts
- #performance
- #css
- #frontend
- #web-vitals
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles