A quick note before we start: most of the tips below involve editing CSS or HTML directly, so this one’s aimed at readers who are comfortable tampering with their site’s code, or at least comfortable pasting a snippet in carefully. If you’re running a well-coded theme or a caching/optimization plugin, there’s a good chance some or all of this is already handled for you. Worth checking before you go editing anything.

Custom fonts make a site feel designed instead of default, but they come with a performance cost that’s easy to overlook. The font file has to download before the browser can render text in it, and depending on how that download is handled, your visitors either see a brief flash of unstyled or invisible text, or wait on a blank screen while your headline loads. Neither is great, but one is much worse than the other, and it’s controllable with a few lines of CSS.

The core problem: fonts are render-blocking by default

By default, most browsers hide text until the custom font finishes downloading. This is called Flash of Invisible Text, or FOIT. If your font takes a second or two to load on a slow connection, your visitor is staring at a blank space where your headline should be. On a slow enough connection, they may bounce before they ever see your content.

The alternative browsers can be told to use instead is Flash of Unstyled Text, or FOUT, where the browser shows text immediately in a fallback system font, then swaps it for your custom font once it’s loaded. There’s a visible swap, but your visitor never sees a blank page.

font-display: the property that controls this

The font-display CSS property, set inside your @font-face rule, tells the browser how to behave while a font is loading. The values you’ll actually use:

• font-display: swap — Shows fallback text immediately, swaps to the custom font once loaded. This is the right default for almost every site, it prioritizes readability over perfect typography during the load.
• font-display: block — Hides text briefly (short block period) then swaps. Rarely worth it for body text, occasionally justified for a logo wordmark where brand consistency really matters.
• font-display: fallback and font-display: optional — More conservative middle grounds that limit how long the browser will wait before giving up on the custom font entirely for that page view. Useful on very performance-sensitive pages.

For most WordPress sites, adding font-display: swap to your font declarations is the single highest-value, lowest-effort performance fix available for text rendering.

Preloading: getting the font file requested earlier

Even with font-display: swap, the swap itself causes a visible flash, and the sooner the font file starts downloading, the sooner that flash resolves. Preloading tells the browser “start fetching this file immediately, don’t wait until you parse the CSS that references it.”

<link rel="preload" href="/fonts/your-font.woff2" as="font" type="font/woff2" crossorigin>

Preload your primary heading and body fonts, the ones used above the fold. Don’t preload every font weight and style you have loaded on the page, that defeats the purpose by competing for the same early bandwidth your critical content needs.

Practical steps for a WordPress site

• Use woff2 format. It’s smaller than older formats and supported by every modern browser, no reason to serve legacy formats to modern visitors.
• Limit the number of font weights and styles you load. Every additional weight is a separate file download. Two or three weights is usually enough for a typical site.
• Self-host your fonts where possible rather than pulling from a third-party font service. It removes an extra DNS lookup and connection, which adds up on mobile connections.
• Free plugins like Perfmatters or WP Rocket’s free-tier features (in caching plugins with free plans) can handle preload injection without manually editing theme files, a good option if you’re not comfortable in code.
• Test with PageSpeed Insights after making changes, font loading issues show up directly as “render-blocking resources” or “ensure text remains visible during webfont load” warnings.

The bottom line

Font loading is one of those performance issues that’s invisible until you know to look for it, and then you’ll notice the flash on half the sites you visit. Setting font-display: swap and preloading your critical fonts takes a few minutes and meaningfully improves how fast your site feels, even before your Core Web Vitals numbers move.