In short
Optimize web fonts by subsetting to only the characters actually used, serving the modern WOFF2 format, using font-display: swap to avoid blocking text rendering, and self-hosting rather than relying on a third-party font-delivery service for an extra request and connection.
Why fonts are an easy performance miss
A custom web font is often added late in a project, without much scrutiny of its performance impact, and left in its default, unoptimized export — full character set, older format, no explicit loading strategy. Each of these is a straightforward, low-effort fix once identified, which makes font optimization one of the highest-return-for-effort performance improvements available.
Subsetting to actual usage
A font file exported with its full character set includes glyphs for languages and symbols your site never uses. Subsetting — generating a font file containing only the characters your content actually needs (Latin characters plus specific punctuation, for instance) — can reduce file size substantially, sometimes by more than half, with zero visible difference for content that only ever uses the included characters.
Choosing the right format
WOFF2 is the modern standard format, well-supported across current browsers and meaningfully smaller than older formats like WOFF or TTF for equivalent quality. Serve WOFF2 as the primary format; a fallback to an older format is rarely necessary given current browser support, unless you have a specific, confirmed need to support very old browsers.
Using font-display correctly
Set font-display: swap in your @font-face declaration so text renders immediately in a fallback system font while the custom font downloads, then swaps in once ready — this avoids the "invisible text" problem where content is blocked from rendering at all until a custom font finishes loading, which is a direct, visible performance and usability cost.
Matching fallback font metrics
Choose a fallback font (in your font-family stack) with similar width and height metrics to your custom font where possible, or use font metric override CSS properties to adjust a fallback's rendering to more closely match — this reduces the visible layout shift that occurs when the page reflows after the custom font swaps in, which otherwise contributes to Cumulative Layout Shift.
Self-hosting versus third-party delivery
Loading fonts from a third-party service (a font CDN) adds an additional DNS lookup and connection that a self-hosted font, served from your own domain, avoids entirely. Self-hosting also removes a dependency on an external service's availability and, for privacy-conscious sites, avoids sending visitor requests to a third party purely to load a font.
Preloading the critical font
For a font used in immediately visible, above-the-fold content (like a headline), add a <link rel="preload"> for that specific font file, which tells the browser to fetch it with high priority earlier in the loading sequence, rather than waiting for the CSS to be parsed before the font request even starts.
A practical checklist
Subset to actual character usage, serve WOFF2, set font-display: swap, choose or tune a metrically-similar fallback, self-host rather than use a third-party CDN, and preload the font used in critical above-the-fold content. Applied together, these fixes typically address the majority of a site's font-related performance cost.
Related on Troiana: A Complete Guide to Web Performance · How to Lazy-Load Images the Right Way.
Common questions
Does subsetting a font actually save meaningful file size?
Often significantly — a font subset to only the characters a site actually uses can be less than half the size of the full character set export, with no visible difference for content within that character range.
Should I always use font-display: swap?
For most sites, yes — it avoids blocking text from rendering while a custom font loads, which is usually a better tradeoff than invisible text, even though it introduces a visible font swap moment.
Is self-hosting fonts better than using a third-party font service?
Generally yes for performance — it avoids an extra DNS lookup and connection to a third-party domain, and also removes a dependency on that service's availability.
