Optimizing a WordPress theme’s web fonts to speed up rendering

Web fonts directly affect how quickly visitors can read your page. They are often requested by the browser only after the HTML and CSS have been parsed. If your theme loads multiple families, weights, italic styles, and full character sets, those files can delay text rendering or cause a visual shift when the final font replaces the fallback font.

To optimize WordPress fonts, the goal isn’t to remove all personality from your site. Rather, it’s to load only the files that are actually needed, at the right time, with a fallback that preserves stable layout. This approach complements the other best practices outlined in this guide on WordPress site speed.

Start by identifying what your theme actually loads

Before changing anything, open an important page of your site in the browser’s developer tools. In the Network tab, filter requests using the term «font» or the extension .woff2. Check specifically for:

• the number of font families downloaded; ;
• the weights actually requested: 400, 500, 600, 700, etc.; ;
• the presence of italic variants; ;
• files that are loaded on every page even though they’re not used; ;
• the origin of the files: your domain, a vendor’s domain, or a plugin.

It’s common to find that a theme, a page builder or a plugin adds its own fonts in addition to those selected in the site settings. If you suspect a plugin is responsible for unused assets, apply a progressive isolation method like the one explained in how to detect WordPress plugins that slow down your site.

Reduce families and variants before any technical optimization

The most reliable reduction is also the simplest: use fewer files. One font for body text and, if needed, another for headings is enough for many themes. Each distinct weight or style can represent an additional file.

So avoid declaring a font in 300, 400, 500, 600, 700 and 800 if your stylesheet actually uses only 400 for body text and 700 for headings. Also be careful with italic styles: load them only if your content or design visibly uses them.

Variable fonts can simplify this management when they cover the needed weights in a single file. However, that doesn’t mean they’re automatically lighter in all cases. Compare the actual file size and the variants your site needs before replacing multiple static files.

The guide Optimize WebFont loading and rendering from web.dev notes that a full font with all its variants and glyphs can become very large. It recommends splitting variants and subsets so the browser downloads only what’s necessary.

Prefer WOFF2 and a subset suited to your content

For modern browsers, serve your files in WOFF2. This format is designed for the Web and usually reduces weight compared with older formats. It’s best to avoid adding multiple formats «just in case» without a demonstrated need: you increase maintenance overhead and complicate resource auditing.

A character subset is just as important. A Canadian French site typically doesn’t need to download all alphabets and symbols available in an international font. However, make sure the subset retains French accents, typographic apostrophes, punctuation marks, and any characters required by your content languages.

Also test your actual pages: menus, product sheets, forms, article excerpts, and imported content. A font that’s too limited can force some characters to render with another font, harming visual consistency.

Host locally or use an external provider: choose methodically

Hosting font files in your theme or in an assets directory gives you direct control over the files, their names, and caching policy. It’s often a clear option when you already have the files with appropriate usage rights and want to limit external dependencies.

An external provider can be justified in some contexts, but it adds an origin to evaluate. If a critical font must come from another domain, the browser also needs to establish that connection. Preloading and connection hints can help in specific cases, but they don’t fix an overly large font catalog.

For a block theme, WordPress allows declaring system families or web fonts in theme.json, using settings.typography.fontFamilies and the fontFace. See the official documentation on typography in theme.json to verify the expected structure and available descriptors.

In a classic theme or when you add a separate CSS stylesheet, load it with the WordPress mechanism intended for that purpose. The WordPress handbook on including assets recommends using wp_enqueue_style() on the wp_enqueue_scripts, hook, rather than inserting a link tag manually in header.php.

Use font-display to avoid invisible text

The rule @font-face accepts the property font-display. It tells the browser how to render text while the font is downloading. Without an explicit strategy, you risk temporary invisible text or a late swap that shifts layout.

@font-face {
  font-family: "MaPolice";
  src: url("/wp-content/themes/mon-theme/assets/fonts/ma-police-latin.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

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

swap allows a fallback font to be shown quickly, then replaced when the web font is ready. It’s often a good default, but it can cause a slight shift if the two fonts have very different metrics. optional leans more toward stability: in some cases the web font might not be used on first render. The choice depends on how important the font’s appearance is and on measured results on your site.

The documentation Optimize Cumulative Layout Shift on web.dev notes that web fonts can produce layout shifts and specifically recommends an appropriate fallback font, as well as the descriptors size-adjust, ascent-override, descent-override and line-gap-override to bring metrics closer when needed.

Preload only the font needed for the first screen

Preloading can request a critical font file early—for example, the one used in the large headline visible on arrival. However, you shouldn’t preload every font. Each resource marked as high priority competes with images, CSS, and other essential items.

<link rel="preload"
      href="/wp-content/themes/mon-theme/assets/fonts/ma-police-latin.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

The preloaded resource must exactly match the file later declared in @font-face. . crossorigin is important: the web.dev documentation on preloading critical assets notes that a preloaded font without this attribute can be downloaded twice. It also recommends using preload sparingly and only for truly critical resources.

Prevent layout shifts with a good fallback font

The fallback font is part of your perceived performance. Choose a generic family consistent with your primary font: sans-serif for a sans-serif font, serif for a serif font. Avoid leaving the browser to pick a default that doesn’t resemble your final font at all.

When shift is still visible, adjust the fallback font with metric descriptors, then compare the display before and after on both mobile and desktop. Pay special attention to headings that wrap to two lines, buttons, and elements near the top of the page.

A short pre-publish checklist

• Keep only the families, weights, and styles you actually use.
• Serve the required files in WOFF2.
• Ensure subsets include the necessary French characters.
• Add a consistent fallback font stack.
• Set font-display and observe its effect on text and visual stability.
• Preload at most the font essential to immediately visible content, after measuring it.
• Test a homepage, an article, and a conversion page with the cache cleared.

Finally, the initial theme choice matters a lot: a theme that requires many fonts and variants will give you less leeway. Before a major change, reread how to choose your WordPress theme wisely to also assess its performance and maintenance implications.