“Ensure text remains visible during webfont load” is one of the more common Lighthouse diagnostics, and one of the easiest to clear. The fix people search for as font display swap is a single CSS property. Add it, re-run the audit, and the warning goes.
What is worth understanding is why the warning appears and what the fix changes for visitors, because it is not free. You are choosing which of two imperfect loading experiences your readers get.
What the Lighthouse font warning means
Chrome’s documentation for the audit, Ensure text remains visible during webfont load, states the rule plainly: “Lighthouse flags any font URLs that may flash invisible text.” The problem it describes is known as FOIT, a flash of invisible text.
It happens because custom fonts are separate files. When a page uses one, the browser may hold back the text set in that font while the file downloads. On a fast connection nobody notices. On a slow mobile connection, a reader can face a page with images and layout but blank spaces where the words should be.
For a content site that is the worst possible failure. The text is the reason the visitor came, and it is the part they cannot see.
Finding the fonts Lighthouse flags
Start with the audit itself rather than your stylesheet. Lighthouse lists the font URLs it is worried about, and that list is often longer than expected. A theme loads one family, a page builder loads another, an icon set loads a third, and a plugin quietly adds a fourth for a single widget. Each is its own file with its own loading behaviour.
Work through the list and note where each font comes from: your own server, Google Fonts, or another third party. That decides how you fix it. Self-hosted fonts need an edit to the CSS. Google Fonts need a change to the URL. Fonts injected by a plugin may need a setting in that plugin, or replacing. Some will turn out to be fonts nobody remembers choosing, and removing those is a better fix than tuning how they load.
How font display swap fixes it
The font-display descriptor controls what the browser does while a custom font loads. Chrome’s documentation says font-display: swap “will tell the browser to use a system font if the custom font is not ready”. Text appears straight away in a fallback font and switches to your custom font once it arrives.
It goes inside the @font-face rule that declares the font. The example in Chrome’s documentation uses the Pacifico typeface:
If you self-host fonts, that one line in each @font-face block is the whole change. Check every weight and style you declare, because each has its own rule and Lighthouse checks each font URL.
Icon fonts deserve a note. They are fonts like any other, so the same rule applies, but a fallback system font cannot draw an icon. With swap, visitors may briefly see an empty box or a stray letter where the icon belongs. That is usually a reason to move icons to SVG rather than to leave the font invisible.
Font display swap with Google Fonts
If you load fonts from Google Fonts, you do not write the @font-face rules yourself, so you cannot add the property directly. Chrome’s documentation gives the alternative: “Add the &display=swap parameter to the end of your Google Fonts URL”.
Google Fonts then serves its @font-face rules with font-display: swap already set. Check the URL your site actually outputs, not the one you think you added: themes and plugins often load their own font stylesheet, and that copy may lack the parameter.
The Google Fonts stylesheet is itself a request the browser has to make before it knows which font files to fetch. That is a separate issue from FOIT, and one covered in our guide to render-blocking resources.
The trade-off: visible text versus a font swap
Swap fixes invisible text by showing a different font first. When the custom font arrives, the text redraws. If the fallback and custom fonts differ in width or line height, lines can rewrap and the content below can move. That is a layout shift, and it counts towards Cumulative Layout Shift.
| Approach | What visitors see while the font loads | Main risk |
|---|---|---|
| No font-display set | Text may be invisible (FOIT) | Lighthouse flags the font URL |
font-display: swap | A system font, swapped when the custom font is ready | Visible font change and possible layout shift |
font-display: optional | The fallback, if the font is not ready quickly | Some visitors may never see the custom font |
Google Fonts with &display=swap | Same as swap | Same as swap |
The optional value is the main alternative. It shows the fallback if the font is not ready quickly, which avoids the late swap at the cost of some visitors seeing the fallback for that page view. For body text on a content site, that is often an acceptable trade. For a brand typeface on headings, it may not be.
You can reduce the swap’s impact by choosing a fallback font with similar proportions to your custom font, so the redraw moves less. Fewer font files help too: every extra weight is another file that can arrive late. On many sites the text block is also the Largest Contentful Paint element, so how quickly readable text appears matters beyond this one audit.
Preloading your most important font file is another lever, because it asks the browser to fetch the file earlier. It shortens the window in which the fallback is shown, but it does not remove it, and preloading too many files competes with everything else the page needs. Keep it to the file that matters most, usually the body text weight.
Does it matter for SEO?
Indirectly. The warning is a Lighthouse diagnostic, not a ranking factor, and clearing it will not move a page on its own. What it protects is the reader’s experience on slow connections, and the layout shift side connects it to metrics Google does report. Our post on the PageSpeed Insights score explains how to read those diagnostics without treating every one as urgent, and our guide to a failed Core Web Vitals assessment covers the metrics that come from real visitors.
One limitation applies. Lighthouse tests a single simulated load, so it tells you which font URLs could cause invisible text, not how often your real visitors see it or how much the swap shifts your layout in practice. Those depend on connection speeds, caching and how different your fonts are, and only field data shows them. After adding swap, check that layout shift has not become the new problem.
The sensible default is clear. Add font-display: swap to self-hosted fonts and &display=swap to Google Fonts URLs. Choose a fallback that looks close to your custom font. Consider optional where a late swap would be more distracting than the fallback. Keep the number of font files small.
Frequently asked questions
What does font-display: swap do?
It tells the browser to use a system font if the custom font is not ready, then swap to the custom font once it loads, so text is never invisible.
How do I add display=swap to Google Fonts?
Add the &display=swap parameter to the end of your Google Fonts URL. Google Fonts then serves its font rules with swap already set.
Can font-display: swap cause layout shift?
Yes. If the fallback and custom fonts differ in size, text can rewrap when the swap happens. A closely matched fallback font reduces the movement.
Should I use swap or optional?
Swap shows your custom font as soon as it loads. Optional shows the fallback if the font is not ready quickly, avoiding a late swap at the cost of the custom font.
The takeaway Add font-display: swap, or &display=swap for Google Fonts, to clear the invisible-text warning. Then pick a close fallback font and keep font files few, so the swap does not become a layout shift problem.
