Show fallback text promptly when readers need the words to use a page. Choose temporary hiding only for a small, justified font-dependent element. For a page you maintain on a Mac, this guide explains how to choose a policy and test its effect on text flow.

What actually changes while a font loads?

A fallback font renders the same text in another typeface while the requested font is unavailable. Temporarily hidden text corresponds to the font-loading block period: the browser lays out an invisible fallback face. The loading timeline begins when the browser first attempts to use the downloadable face. MDN’s font-display reference explains these stages.

That distinction matters when reviewing a page. A blank heading does not establish that its final dimensions have been reserved. The browser is still using fallback layout during the block period; hiding the letters does not establish the downloaded font’s eventual line breaks. Judge visibility and layout stability separately.

The relevant control is the font-display descriptor inside an @font-face rule. It belongs to the font-face definition, rather than an ordinary paragraph selector. This is a page-authoring choice: use the stylesheet or font settings available for the page you maintain. MDN documents where font-display applies.

Which font-display value fits the reader’s task?

Decide two things before editing: whether the words should appear promptly in another font, and whether replacing that font later is acceptable. The following table translates the documented loading periods into choices for an abstract public page. MDN’s value definitions describe the underlying behavior.

Value While the face is unavailable Opportunity to replace fallback Appropriate starting point
swap Extremely brief blocking, then visible fallback Unlimited swap period A short heading whose intended typeface matters
fallback Extremely brief blocking, then visible fallback Short swap period Reading text where an early change is acceptable
optional Extremely brief blocking No swap period Text where keeping the first visible font matters most
block Invisible fallback during a short block period, then visible fallback Unlimited swap period A small element with a specific font dependency
auto Browser-selected policy Browser-selected policy Accepting the browser’s default behavior

These are policy categories, not exact timers you can configure. W3C’s current CSS Fonts Level 4 working draft recommends typical durations but explicitly allows browser variation. It also restricts block to small pieces of text whose particular font is required for usability. A preference for a heading’s appearance alone is a weak reason to leave it blank. W3C: Controlling Font Display Per Font-Face.

For a synthetic page with a heading named “Sample Collection,” navigation named “Section One,” and several paragraphs, start by considering fallback for reading text. Consider swap for the short heading if eventual use of its typeface is important. Choose optional when retaining the first visible rendering takes priority. These recommendations apply the documented policies to the reader’s task; they are not measured results.

Use a visibility-and-reflow decision aid

Evaluate each text role separately. A navigation label and a paragraph may use the same family, but their layout constraints differ. The useful question is whether a font change prevents someone from continuing the task or merely changes the appearance.

  1. Read the page in its fallback font. Can someone understand “Section One,” identify the heading, and read the paragraphs? If so, visible fallback is a viable starting point.
  2. Observe the font replacement. Does the heading gain a line? Do labels wrap? Does the next paragraph move?
  3. Choose the acceptable replacement window. Use swap when a late replacement remains acceptable, fallback when only an early replacement is welcome, or optional when the first visible font should remain.
  4. Require a concrete reason for blank text. Before choosing block, identify what would become unusable in fallback and why that dependency cannot be removed.

For example, suppose “Sample Collection” occupies one line in fallback and two in the downloaded font. If the heading has a hypothetical line height of 40 pixels, the additional line contributes 40 pixels to its height, assuming unchanged spacing. Content below it may move accordingly. These are illustrative inputs, not browser measurements.

Temporary hiding does not solve that mismatch. The practical choices are to improve the fallback match, adjust the layout after testing, or select a policy that avoids a late replacement. Under the current W3C draft’s optional behavior, once fallback text has been painted, the optional face must not replace it during that page’s lifetime. W3C’s optional definition.

How to apply and test the choice on a Mac

Use a page whose stylesheet you can edit and whose existing web font already loads successfully. Keep its actual font file reference; no new font download or substitute asset is necessary for this comparison.

Find the relevant @font-face declaration in the page’s source stylesheet or supported font configuration. Set its font-display descriptor to the candidate value, such as font-display: fallback;. Review the other declarations used for weights and styles so the test covers the faces the page actually requests. The descriptor’s placement is shown in MDN’s font-display example.

In Chrome on your Mac, press Command + Option + I to open DevTools. Alternatively, right-click the target text and choose Inspect; the Elements panel shows its applied CSS in Styles. Chrome’s DevTools opening instructions document both paths.

Run the following comparison after each stylesheet change. Keep the window width and zoom consistent so you can attribute differences to the font-loading policy.

  1. Open Network, enable Disable cache, select a slower preset from the Throttling menu, and reload. Use the Font filter to focus on font requests.
  2. Watch the heading, navigation, and paragraph opening. Record whether text starts blank, appears in fallback, and later changes its line breaks.
  3. If the transition is too quick to inspect, enable Capture screenshots in the Network panel settings and reload to inspect the loading sequence.
  4. Disable throttling and clear Disable cache. Reload again to compare a repeat visit under normal conditions. Chrome’s Network features reference documents these controls.

Test the unavailable-font outcome separately. In Network, right-click the actual font request and select Block request, then reload. Chrome lists the matching pattern in Request conditions. Check that the words become readable and that the page remains usable in fallback. Remove or disable the test pattern afterward. Chrome’s request conditions documentation explains request blocking and how to identify blocked requests.

Repeat the page review in Safari if it is part of your intended Mac browsing environment. Treat the Chrome test as evidence about that browser’s rendering, rather than proof of identical timing elsewhere: the specification permits browser differences. Keep a small comparison note with the browser, candidate value, initial visibility, and observed wrapping.

What if visible fallback changes the layout too much?

Start with the actual text and available width. Compare short labels, the longest heading, and several paragraph lines. A fallback that resembles the web font visually may still have different character advances and produce different wrapping.

For closer matching, size-adjust scales a face’s glyph outlines and metrics, including glyph advances. MDN demonstrates defining a local fallback face and adjusting it to better match a primary web font. Determine an appropriate percentage for your actual pair; a documentation example’s percentage is not a universal setting. MDN: size-adjust.

Vertical metrics deserve a separate check. The ascent-override descriptor controls the metric above the baseline used in laying out line boxes, but MDN currently marks it as having limited availability. Treat that adjustment as an enhancement, and retain a readable fallback layout in browsers that do not support it. MDN: ascent-override.

Keep text shaping with the browser. Do not try to stabilize a heading by replacing or measuring each character independently. CSS font matching includes special handling for grapheme clusters, such as a base character with a combining mark. Inspect complete labels and lines in their real layout. W3C: Cluster matching.

Do preload or a font-loading library change the decision?

Preloading addresses resource discovery. The WHATWG HTML Standard defines preload as preemptively fetching and caching a resource expected for the current navigation. It does not select your font-display policy. Consider it only after choosing acceptable visible behavior; earlier fetching cannot substitute for deciding what happens when the face is still unavailable. WHATWG: Link type preload.

For ordinary page text, begin with CSS. If an existing project uses Font Face Observer, its documented load() method returns a promise that resolves when the font loads and rejects on failure. Its family name and optional weight, style, and stretch description should match the requested face. The library also documents supplying suitable test text when its default characters are absent from the font. Font Face Observer documentation.

A successful library callback is a loading signal; your application still determines what becomes visible. If custom logic hides text, specify a failure path that restores readable fallback. Otherwise, a rejected load can leave the application’s hiding rule in place. This is an implementation recommendation derived from the library’s documented success and failure paths.

The native API has a similar boundary. document.fonts.ready fulfills after loading and layout operations for used fonts complete; that set can differ from all declared fonts, including optional faces that missed their opportunity. It therefore does not prove that every intended face is visible. MDN: Document fonts property.

Likewise, the optional text argument to document.fonts.load() selects matching faces through their Unicode ranges; it does not check individual glyph coverage. Loading completion and correct rendering of the complete sample remain separate checks. MDN: FontFaceSet load() method.

Choose the policy by reviewing the slow, unavailable, and repeat-load versions of the same page. Keep ordinary words readable, decide explicitly whether a late replacement is acceptable, and accept temporary hiding only where a small element has a demonstrated font dependency. The result should let someone continue reading “Sample Collection” comfortably under each tested condition.

Sources