What is font-display and how do swap and block differ?
This tests knowledge of the font display timeline. Swap shows fallback immediately then swaps in custom font, while block hides text for a short block period before fallback. A red flag is claiming swap prevents layout shift or that block is superior.
What's really being asked
Whether you understand the font display timeline defined in CSS Fonts Module Level 4 and can evaluate the user experience trade-offs between showing content immediately and avoiding layout shift. Interviewers want to see that you know font-display is a descriptor for the @font-face at-rule, not a standalone property, and that you can pick the right strategy for different font use cases.
The full answer
Four things in order. First, the timeline has three periods: the font block period where text is invisible if the font is not loaded, the font swap period where a fallback font is shown, and the font failure period where the fallback becomes permanent. Second, swap gives an extremely small block period and an infinite swap period, so users see fallback text almost instantly and the custom font replaces it whenever it arrives; this is good for body text but can cause cumulative layout shift. Third, block gives a short block period and an infinite swap period, so text is invisible for up to roughly three seconds before fallback appears, and the custom font can still swap in later; this is often used for icon fonts where showing a fallback character would be confusing. Fourth, you should mention that neither is universally better and that the choice depends on whether readability or visual stability matters more for the specific element.
The mistakes people make
Saying that font-display is a regular CSS property instead of an @font-face descriptor. Claiming that swap prevents layout shift when it actually increases the risk of shift because glyph metrics change. Recommending block for all text without acknowledging the flash of invisible text, which hurts perceived performance and accessibility. Confusing block with optional, or stating that block never shows a fallback.
What usually comes next
How would you mitigate layout shift when using swap? When would you use fallback or optional instead? How does this interact with the preload resource hint? What happens if the custom font fails to load entirely? How do you measure the impact of font loading on Core Web Vitals?
A concrete example
Imagine a news site using a custom serif for article body copy. Using swap means the user can start reading the headline and paragraphs instantly in system Georgia, but when the custom font arrives two seconds later the paragraph lines may rewrap and buttons may shift, hurting CLS. Using block means the user stares at invisible or missing text for up to three seconds, which feels broken on slow networks, but once text appears it does not change metrics. A senior candidate might suggest swap for body text combined with a size-adjust descriptor or preloading to reduce shift, and block only for a branded display heading where the flash of invisible text is brief and the layout impact of swap would be severe.
Interview question
When choosing font-display: swap over block for body text, what key user experience trade-off should you expect?
- a.Swap hides text for roughly three seconds before showing a fallback, while block renders fallback text instantly and never swaps in the custom font.
- b.Swap prevents cumulative layout shift by matching fallback metrics, while block causes a flash of invisible text that persists until the custom font loads.
- c.Swap shows fallback text almost immediately but risks layout shift when the custom font arrives, while block hides text briefly to avoid initial metric changes.Correct
- d.Swap is a standalone CSS property applied to selectors, while block is an @font-face descriptor recommended for all text to maximize readability.
Why? this is the answer
Swap displays fallback text within an extremely short block period but risks cumulative layout shift when the custom font metrics replace the fallback, whereas block hides text for a short block period to preserve initial visual stability. Distractor B is tempting but wrong because swap increases, not prevents, layout shift risk.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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. Open roles that interview on css — each one lists the topics its interview covers.
See open roles