Fix the “Ensure text remains visible during webfont load” warning in WordPress by adding font-display: swap; to your webfont CSS, preloading key font files, and trimming unused font weights. This keeps fallback text visible while custom fonts load, so visitors are not staring at blank headings or invisible body copy for a second or two.

TLDR: WordPress sites often hide text while Google Fonts, Adobe Fonts, or theme fonts load, which hurts perceived speed and can trigger PageSpeed Insights warnings. Add font-display: swap;, preload only your most-used font files, and remove extra weights such as 300, 500, 600, 700, and 900 if you do not need them. For example, a small WooCommerce site that cut its font files from 9 to 3 and added font-display: swap; reduced Largest Contentful Paint from 3.8 seconds to 2.6 seconds on mobile. That is the kind of boring fix that users actually feel.

Why text disappears during webfont loading

When a browser finds a custom webfont, it needs to download the font file before rendering text in that typeface. Some font setups tell the browser to wait. That waiting period can create FOIT, or Flash of Invisible Text.

FOIT is exactly what it sounds like. Text is present in the HTML, but the browser does not show it yet. It drives me crazy that a page can technically be loaded while the visitor still cannot read the headline.

The fix is to tell the browser: “Show a fallback font now, then swap in the custom font when it is ready.” That is what font-display: swap; does.

PageSpeed insights

What the PageSpeed warning means

Google PageSpeed Insights may show a warning like:

“Ensure text remains visible during webfont load.”

This warning means at least one font file is loaded in a way that may hide text. It is common on WordPress sites because themes and plugins often add fonts automatically. A page builder may load one family. A slider may add another. A cookie banner may bring its own icon font. Before long, your site is carrying a tiny font circus.

The result can include:

  • Invisible text during the first load.
  • Slower first paint, especially on mobile.
  • Layout shifts when the custom font replaces the fallback.
  • Lower Core Web Vitals scores.
  • Higher bounce rates on slow connections.

The best fix: use font-display: swap;

If you load fonts through CSS with @font-face, add font-display: swap; inside each font declaration.

@font-face {
  font-family: 'Inter';
  src: url('/wp-content/uploads/fonts/inter-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

This tells the browser to show a system fallback font first. When the custom font finishes loading, the browser swaps it in. The user can read the page right away, even if the final font arrives a moment later.

For most WordPress sites, swap is the safest choice. It favors readability and speed over visual perfection during the first second.

If you use Google Fonts in WordPress

Google Fonts supports font-display=swap in the font URL. A proper Google Fonts URL may look like this:

<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap" rel="stylesheet">

See the &display=swap part at the end? That is the key.

Many modern WordPress themes already add this. Some older themes do not. Some plugins also load Google Fonts without it. Expect to waste time finding the source, because the font may not come from the place you think it does.

To check, open your site in Chrome, right-click, choose Inspect, then open the Network tab. Filter by font or search for fonts.googleapis.com. If the URL does not include display=swap, you have found a likely issue.

How to fix it in WordPress without editing theme files

You have several practical options. The right one depends on how your site loads fonts.

  • Use your theme settings. Some themes include a performance setting for Google Fonts display behavior. Choose swap if available.
  • Use a performance plugin. Plugins such as WP Rocket, Perfmatters, LiteSpeed Cache, and Autoptimize may include font optimization settings.
  • Host fonts locally. Local hosting gives you more control over @font-face, caching, and preloading.
  • Disable plugin fonts. If a plugin loads its own font but you do not need it, turn that option off.
  • Add custom CSS only when needed. If you manage local fonts, add font-display: swap; to every @font-face rule.

Preload the most important font files

font-display: swap; keeps text visible. Preloading can make the final font appear sooner.

Preload only the fonts used above the fold. Usually that means your regular body font and maybe one bold weight for headings. Do not preload every font file. That can slow the page instead of helping it.

<link rel="preload" href="/wp-content/uploads/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin>

Use WOFF2 when possible. It is smaller than older formats and widely supported.

Reduce font weights and styles

This is where many WordPress sites get messy. A theme may load six weights for one font family. Then the page uses only regular and bold. The other files still cost time.

Keep your font setup lean:

  • Use 400 for body text.
  • Use 700 for bold text or headings.
  • Avoid loading italics unless you use them.
  • Skip decorative fonts on mobile if they hurt speed.
  • Use one or two font families, not five.

One font family with two weights is often enough for a clean site. Your visitors are not counting font weights. They are trying to read, compare, buy, or contact you.

Use system fonts for instant rendering

If speed matters more than brand styling, system fonts are the fastest option. They are already installed on the visitor’s device. No download is needed.

body {
  font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

This stack gives a native feel across devices. It also removes the font loading problem for body text. Many high-traffic sites use system fonts because they are quick, stable, and easy to maintain.

Watch for icon fonts

Not every font file contains readable text. Some are icon fonts from libraries such as Font Awesome. These can also trigger performance warnings.

If your site uses only a few icons, replace icon fonts with inline SVGs. SVG icons are usually smaller, sharper, and easier to control. They also avoid loading a full font file just to show a search icon and a shopping cart.

Optimising Core Web Vitals on review hubs

Test the fix properly

After making changes, clear every cache. That includes your WordPress cache, CDN cache, server cache, and browser cache. Then test again.

Use these tools:

  • PageSpeed Insights for field and lab data.
  • Chrome DevTools to inspect font requests.
  • WebPageTest to see filmstrips of text rendering.
  • GTmetrix for waterfall charts.

Check the mobile score first. Mobile users suffer most from slow font loading. If text appears quickly on a throttled mobile test, you are in good shape.

Common mistakes to avoid

  • Preloading too many fonts. Preload only critical files.
  • Loading fonts from several sources. Keep them local or from one provider.
  • Using heavy font families. Variable fonts can help, but only if configured well.
  • Ignoring fallback fonts. Pick fallbacks with similar size to reduce layout shifts.
  • Forgetting plugin fonts. Forms, sliders, popups, and builders may load their own assets.

Best setup for most WordPress sites

For a typical WordPress business site, use one main font family, two weights, WOFF2 files, local hosting, and font-display: swap;. Preload the regular font if it is used above the fold. Use a similar fallback font to keep layout shifts small.

This simple setup improves page rendering performance without making the site harder to manage. It also makes the first visit feel faster, which matters more than a perfect font appearing half a second earlier. Keep the text visible first. Style can catch up.