Guide

Web Font Performance: How to Load Custom Fonts Without Slowing Your Site

Beautiful typography that doesn’t slow your site down.

Custom web fonts make a significant difference to how a website looks and feels — they reinforce brand identity and improve readability in ways that system fonts rarely match. But they come with a performance cost. Fonts must be downloaded before they can render, and if that download is slow, visitors see either a blank space where text should be (Flash of Invisible Text) or a jarring swap from a system font to the custom one (Flash of Unstyled Text). Both are poor experiences.

Getting web font performance right is a combination of choosing the right formats, loading them efficiently, and giving the browser the right hints about what to expect. This guide covers the full picture, from Google Fonts to self-hosted variable fonts. At Xpose, font loading strategy is part of every performance audit we conduct.

Choosing the Right Font Format and Loading Method

WOFF2 is the standard format for web fonts — it offers the best compression and is supported by all modern browsers. If you’re self-hosting fonts, WOFF2 is the only format you need to provide. Avoid loading TTF or OTF files on the web — they’re significantly larger than WOFF2 equivalents. Variable fonts are worth considering for sites that use multiple weights of the same typeface: a single variable font file can replace four or five separate weight files, reducing HTTP requests and often total download size.

For Google Fonts, the easiest performance improvement is to self-host rather than load from Google’s CDN. Tools like google-webfonts-helper.herokuapp.com let you download the WOFF2 files and generate the @font-face CSS. Self-hosting eliminates the DNS lookup and connection to fonts.googleapis.com and fonts.gstatic.com — which, though usually fast, adds latency and a privacy-related third-party request. It also means your fonts load even if Google’s servers have an outage.

Preloading, Preconnecting, and Font-Display

Tell the browser about your fonts early using resource hints. <link rel="preload" as="font" href="/fonts/myfont.woff2" crossorigin> in the <head> signals to the browser that this font is critical and should be fetched as a high priority, even before the CSS that references it is parsed. This can significantly reduce the time before the font is available. Use preload sparingly — only for the one or two fonts actually needed for above-the-fold content.

The font-display CSS property controls what happens while the font is loading. font-display: swap tells the browser to show a system font immediately and swap to the custom font when it arrives — this prevents invisible text but causes a layout shift. font-display: optional tells the browser to use the custom font only if it’s already cached; otherwise fall back to the system font permanently for that page load. For most business websites, font-display: swap offers the best balance. If cumulative layout shift (CLS) from the font swap is a concern, consider font-display: optional or use a system font stack that closely matches your chosen typeface.

Minimising the Number of Font Variants

Every additional font weight or style is a separate download. Designers often specify four or five weights (Regular, Medium, Semi-Bold, Bold, and their italic variants) without considering the performance cost. On a page that actually uses three weights, loading five adds 30–40% unnecessary weight in font files. Audit your CSS for @font-face declarations and check which weights are genuinely used in the stylesheet. Remove any that aren’t referenced.

If your design uses more than two typefaces, question whether that complexity is necessary. Two well-chosen typefaces — one for headings, one for body text — typically serve all needs. Using a variable font for both can consolidate multiple weight downloads into one or two files. The performance target: aim for total font download size under 100KB, and ideally under 50KB. At Xpose, we advise clients on typography choices during the design phase with performance built in from the start, rather than trying to retrofit font optimisation after the fact.

FAQs

Common questions.

Should I use Google Fonts or self-hosted fonts?
Self-hosted fonts are better for performance and privacy. They eliminate the third-party DNS lookup, give you full control over caching headers, and ensure GDPR compliance (loading Google Fonts sends visitor IP addresses to Google, which requires disclosure under UK GDPR).
What is a Flash of Invisible Text (FOIT)?
FOIT occurs when a browser hides text until the custom font has loaded. The visitor sees blank spaces where text should be for the duration of the font download. This is caused by font-display: block (or the default browser behaviour in some older browsers). Use font-display: swap to avoid it.
Are system font stacks a good alternative to custom fonts?
Yes, for sites where performance is the top priority. System fonts like -apple-system, BlinkMacSystemFont, and Segoe UI are already on the visitor’s device — zero download required. They’re crisp, readable, and render immediately. Some brands — particularly modern, tech-oriented ones — deliberately use system fonts to signal speed and efficiency.
Related guides

More on web design & ux.

Want a hand putting this into practice?

Book a free, no-obligation consultation with a Norwich-based specialist.

Book a free consultation
Get started

Let's put your business in a better light.

Book a free, no-pressure consultation. We'll talk through your goals and tell you honestly what we'd do — whether you work with us or not.

  1. 01
    Tell us a bitFill in the form — two minutes, tops.
  2. 02
    We'll call you backWithin one working day, no pressure.
  3. 03
    Get a clear planHonest advice and a fixed quote.

Free · No obligation · We reply within one working day

Book a free consultation