Typography influences how a website feels, but font choices also add requests, transfer size, and rendering decisions. A design using several families and many weights can make the browser work harder before the page settles. A font budget helps a team choose the typography it needs while keeping text readable and the layout stable during loading.
This guide uses a fictional educational website with headings, body text, navigation, and code examples. The objective is to create a documented font plan, compare alternatives, and test the visible result. A font budget is not a rule that every site must look identical. It is a way to make the cost of typographic choices explicit.
Inventory the fonts actually requested
Start with a network audit rather than the design specification. A theme, page builder, widget, and embedded form may each request fonts independently. Record the family, weight, style, file format, URL, and which component uses it. Some requested files may not contribute to the page being reviewed.
Compare that inventory with computed styles on important text. A declared family might fail to load, leaving a fallback in use. A font can also be downloaded twice from different locations. Identifying the actual requests prevents optimisation work from focusing on a file that the visitor never uses.
Define typographic roles
List the roles the site needs: body, headings, navigation, labels, and code. A separate family for every role is rarely necessary. The fictional site may use one readable family with a small set of weights, plus a system monospace stack for code. The final choice should reflect readability and brand requirements rather than an arbitrary minimum.
Ask whether italic and heavy weights are genuinely used. Removing an unused style can avoid an unnecessary request without changing the design. Record which components depend on each file so later edits do not reintroduce the full family by default. A budget works best when it is tied to visible requirements.
Consider a system-font baseline
System fonts avoid downloading a custom font file, although appearance differs across operating systems. Use a baseline version of the page to see whether that trade-off is acceptable. For dashboards, documentation, or lightweight landing pages, a carefully chosen system stack may provide an appropriate experience.
If a custom font is important, compare it against the baseline rather than assuming it is free. Note the visual benefit and the additional requests. This makes the decision understandable to both designers and developers. Performance work should preserve intentional design choices while removing accidental costs.
Choose loading behaviour deliberately
The font-display descriptor affects how text behaves while a font loads and whether a later substitution occurs. MDN documents its options in the font-display reference. Choose a strategy according to the importance of the typeface, expected connection conditions, and tolerance for later visual changes.
Do not judge only the final screenshot. Observe the page before the font arrives and during the swap. Text may wrap differently, moving buttons or changing the height of a hero section. A loading choice that makes text visible quickly can still require attention to fallback metrics and available space.
Design a useful fallback
A fallback should remain readable and reasonably close in proportions to the intended font. Compare line breaks in the longest heading, navigation items, form labels, and body paragraphs. A dramatically wider fallback can turn a two-line heading into four lines and move the call to action before the final font arrives.
Avoid solving every shift with fixed heights that clip translated or enlarged text. Test longer content, text zoom, and narrow layouts. Where advanced font-metric adjustments are used, document and verify them for the chosen fonts. The goal is stable readable text, not a screenshot that works for one exact sentence.
Evaluate variable fonts with real files
A variable font can provide multiple weights or styles in one resource, but it is not automatically smaller than every alternative. Compare the actual variable file with the subset of static files the site needs. A page using only regular and bold may have a different trade-off from a design using many weights.
Check the supported axes and how the CSS selects them. Do not download a broad font resource while using only a narrow part of its range without considering alternatives. Test the displayed result across the supported browsers and retain the source and licensing information in the asset register.
Subset carefully
Subsetting can remove characters the site does not need, but an incorrect subset can break names, symbols, or multilingual content. Identify the languages and special characters that must work before changing a font file. A local business site may need more than the letters visible on the homepage today.
Check currency symbols, punctuation, accented names, and any language used in forms or content. Also consider future editorial work. If a subset is too restrictive, the browser may mix fonts within a word or display missing glyphs. Record the coverage so future maintainers understand the limitation.
Use preload sparingly
Preloading can help a critical font become available earlier, but every preload competes for network resources. Choose only a resource that the page definitely needs early. Verify the URL, format, and request settings against the actual font request. An incorrect preload may add work without satisfying the later request.
Inspect the network timeline after the change. The important question is whether the intended font becomes useful sooner without delaying more important content. Preloading every weight is not a substitute for selecting fewer files. Keep the preload decision in the same review as image and stylesheet priorities.
Test slow and failed loads
Test the page under a constrained connection and with the font request unavailable. Visitors should still be able to read the offer, navigate, and complete forms. A custom font is a presentation resource, so the site should remain usable when that resource cannot arrive.
Record any layout movement or text invisibility observed during the test. Check more than the homepage: long article titles, small cards, menus, and validation messages can expose problems. A typography change applied globally needs representative coverage of the components that use it.
Set and monitor a budget
Define acceptable families, styles, request counts, and transfer ranges for the project. These are local targets, not universal standards. Add a review requirement when a component introduces another family. This prevents the font inventory from growing invisibly through third-party widgets and copied page templates.
Document actual before-and-after measurements. A reduction in font bytes is a factual result; a rendering improvement needs a comparable runtime measurement. Google’s font performance guidance discusses the loading lifecycle and its relationship to rendering. Use it as a technical reference alongside your own page evidence.
Beginner project exercise
Build three versions of the same fictional course page: system fonts, two static custom weights, and one variable font. Keep layout, content, and images identical. Record requested font files, transferred bytes, first visible text behaviour, and heading wrapping. Explain which version best serves the project and why.
The strongest portfolio result may be a justified compromise rather than the smallest file total. Include a handover note explaining fallbacks, supported languages, licensing, and how to review future font additions. This shows that performance decisions are part of maintainable design.
Frequently asked questions
Does self-hosting always improve font speed?
No. Delivery, caching, file choice, and connection behaviour all matter. Compare the actual implementation instead of assuming that a hosting location guarantees a faster result.
Can font loading cause layout movement?
Yes. Different character metrics can change line breaks and element heights. Test the fallback and loaded states with realistic content and narrow layouts.
Is one font family always enough?
Not necessarily. Use the families needed for the design, but make each additional resource an intentional, measured choice.