What is font-display and how do swap and block differ?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: developer.mozilla.org