Font loading without hurting performance

Typography is part of the brand, but fonts can easily become a render-blocking dependency.

We use framework-supported font loading

Next.js font tooling can self-host and optimize fonts so the page is not waiting on an uncontrolled third-party request.

Limit the number of families and weights

Every additional font file is another resource. We avoid loading weights that the design never uses.

Use display strategies that protect readability

The page should not remain invisible while a custom font downloads. A system fallback can render immediately and swap cleanly when the custom face is ready.

Keep typography consistent

A smaller font system is easier to cache, easier to maintain, and easier to keep visually consistent across the site.

Fonts are not worth a slow first render

Brand identity matters, but a font choice should not force the visitor to wait for the page. We treat typography as part of the performance system rather than as a purely visual decision.

Our repos make font priority explicit

Several of our Next.js projects use next/font rather than loading a remote font stylesheet in the page head. That lets the framework integrate the font files into the build and gives us more control over how the families are loaded. On one production site, the primary sans-serif family is preloaded while a secondary display serif is explicitly not preloaded. That is a small decision with a clear reason. The primary family affects most of the first viewport. The decorative family is important to the brand, but it does not deserve to compete equally for the earliest bandwidth.

More weights mean more files

A design can ask for light, regular, medium, semibold, bold, and black weights. If the actual site only uses three of them, loading the rest is waste. The same is true of italics and language subsets. We prefer to define the typographic system around the weights the interface actually uses. That makes the design more consistent and keeps the font payload easier to reason about.

Fallbacks are part of layout stability

The fallback font should be readable and reasonably compatible with the final face. Large metric differences can cause text to reflow when the custom font becomes available, which can contribute to layout shift. We use display: swap behavior so text remains visible rather than hiding the page until the custom asset arrives.

The ideal result is not that the user notices the font loading. The ideal result is that they can read immediately and the final typography settles without a distracting jump.

Brand value still matters

Performance work is not an excuse to reduce every site to the same system font. Typography carries personality, hierarchy, and trust. The engineering job is to preserve that value while loading the smallest practical font system. This is the same principle described in How we decide what gets to load before the page becomes useful: early bandwidth is a priority queue. The assets that define the first useful view get priority, and secondary decoration waits its turn.

Preload is a priority decision, not a compliment

Preloading a font tells the browser that the resource matters early. That can be useful for the primary interface face that appears throughout the first viewport. It can also waste bandwidth if the font is decorative, used only in a later section, or loaded in weights that the first view never needs.

On some of our sites, the main type family is treated as critical while a secondary display face is intentionally allowed to arrive later. The design still gets its distinctive typography, but the browser is not forced to fetch every possible face before it can settle the initial page.

This is the same priority model we use for images and scripts. Early bandwidth should go to what makes the first screen useful.

Fallback fonts affect layout stability

A font swap can move text if the fallback and final typeface have very different metrics. That can change line breaks, button widths, navigation spacing, and hero height.

We therefore test the fallback state instead of assuming the final font will appear instantly. A reasonable system fallback should keep the page readable and close enough in geometry that the custom face does not reorganize the interface when it arrives.

This matters most on dense navigation, large headings, and tightly composed heroes.

Self-hosted does not mean cost-free

Framework-managed or local fonts remove a third-party stylesheet request and give us more control, but the files still have to be downloaded.

The browser does not care whether a 200 KB font came from our domain or somebody else's. File count, subset, compression, and weight selection still matter.

A self-hosted font system is useful because it gives us control over those variables. It is not automatically fast because the URL is local.

We test typography as part of the page

A font decision is finished when the page still works across viewports, the fallback is acceptable, the important text appears promptly, and the number of files matches the design rather than the font family's entire catalog.

That is why font loading lives in performance documentation instead of being treated as a branding-only concern.