You can use custom fonts without hurting page speed by shipping fewer, smaller font files, choosing a sensible font-display setting and making the fallback font match the web font closely so text does not jump when the font loads. The biggest wins usually come from using WOFF2, removing unused weights and glyphs, and deciding honestly whether body text needs a web font at all.
What goes wrong with fonts
A font is a file the browser must fetch before it can draw text in that style. While it waits, the browser either hides the text or shows a fallback, and when the real font arrives the layout can shift. Both effects hurt: invisible text delays what the visitor came to read, and shifting text feeds layout instability, which matters for Core Web Vitals.
Choose a font-display value on purpose
MDN describes three periods in a font’s life: the block period (text is invisible), the swap period (a visible fallback is shown and replaced if the font arrives) and the failure period. The font-display descriptor in @font-face sets how long each lasts:
| Value | Behaviour | Typical use |
|---|---|---|
auto |
The browser chooses | Rarely the best explicit choice |
block |
Short invisible period, then fallback until the font loads | Icon-like or brand-critical type |
swap |
Fallback shown almost immediately, swapped whenever the font arrives | Brand-critical headings |
fallback |
Fallback first, swaps only if the font arrives soon enough | A balanced default |
optional |
Fallback first; font used only if already available, no later swap | Performance first |
web.dev’s font best practices page suggests optional for performance, since it limits text delay to about 100 ms but may skip the web font if it arrives late, and swap when text must appear quickly and the font is important to the brand. Note that MDN does not give exact durations for “short” and “extremely small” periods, so test on real devices and connections.
@font-face {
font-family: "BrandSans";
src: url("/fonts/brandsans-regular.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}The practical checklist
1. Use WOFF2 only
web.dev says WOFF2 offers the best compression with broad browser support, quoting an expert’s advice to use only WOFF2 and forget about everything else. That removes the old pile of TTF, EOT and WOFF variants.
2. Subset the font
Removing unused glyphs can significantly reduce font file size, according to web.dev. If your site is in English only, you may not need Cyrillic, Greek or large symbol sets. Check the font licence first, because some licences restrict modification or subsetting. If you publish in Chinese, remember that character sets are large; plan subsetting and fallbacks carefully, and see localisation vs translation for the wider picture.
3. Limit families and weights
Every weight and style is a separate file in most setups. A site with regular, italic, bold and bold italic in two families can load eight files. Often two or three are enough. Variable fonts can replace several static files with one, though a variable file can be larger than a single static weight, so compare actual sizes.
4. Preload only what is critical
Preloading helps the browser find a critical font sooner, but web.dev warns that it takes resources from other loads and ignores unicode-range declarations. Preload one or two fonts used above the fold, in one format, not everything.
5. Self-host thoughtfully
web.dev notes that self-hosted fonts are not automatically faster: the benefit depends on using a CDN and HTTP/2, and you take on the optimisation work third-party providers usually handle, such as subsetting and WOFF2 compression. Self-hosting does remove a third-party connection and gives you control over caching and privacy. Check the font licence allows it.
6. Reduce layout shift with a matched fallback
The size-adjust descriptor lets you scale the fallback font so its metrics are closer to the web font, reducing layout shift when the swap happens, per web.dev. Choose a fallback stack deliberately rather than leaving it to chance.
7. Consider system fonts
Using system-ui avoids a download entirely, and web.dev notes system fonts can work particularly well for body text. A common pattern is a distinctive web font for headings and a system stack for paragraphs. The trade-off is that system fonts differ between devices, so your typography will look slightly different on each.
Testing
Test with throttled network settings in browser developer tools, watch for invisible text and shifts, and check on a real mid-range phone. Compare the rendered result against your brand guide, since a fallback that looks very different may be worse for brand consistency than a short delay. The principles in consistent visual identity across channels help decide how strictly type must match everywhere.
Limitations
There is no single best setting. A luxury brand whose logotype relies on a specific face may accept a short delay; a text-heavy information site should favour readability first. Platform choice also matters: some CMS themes load many font files by default, which is one factor in the Astro vs WordPress comparison. And typography is only one part of speed, so see business website conversion for the larger picture.
Where Radiance Impact fits
Radiance Impact’s Technology division builds business websites and landing pages with attention to performance and maintenance. If your site loads slowly and you suspect fonts, images or scripts, see Technology or contact us.
Sources
- Best practices for fonts, web.dev (Google)
- font-display, CSS @font-face descriptor, MDN Web Docs
