Start with the reader
A font decision is a service decision when a customer must read prices, dates, eligibility and instructions on a phone. The attractive typeface in a design file does not tell you whether a real page will show text promptly or whether a fallback will move a checkout button after the customer starts reading. Begin by listing the page elements that must remain legible: product names, small conditions, input labels, error messages and confirmation text. Include both English and Traditional Chinese, because a Latin sample cannot reveal missing Chinese glyphs or unexpected font substitution. A sensible acceptance goal is plain: each language stays readable if the custom font is late or unavailable, and the page does not move enough to interrupt the task. This is an editorial and usability goal, not a claim that one font setting guarantees a particular performance score.
Audit the actual files
Ask the developer for the fonts the live page actually requests, not only the names in the style guide. Record each family, weight, style, file format, language subset and page where it is used. A regular body face and a bold heading face may be separate downloads; an unused italic face can still become a download if CSS accidentally references it. Google’s font guidance explains that a complete font with many styles and glyphs can be large, and that font faces and Unicode ranges let a browser request needed resources. The decision is therefore to remove unused faces before changing network priority. Check licence terms for the chosen font and its self-hosting or external delivery route separately; performance guidance does not grant usage rights. Give design and engineering one shared list so visual approval refers to the same files that will ship.
Decide what needs a custom face
A small business does not have to apply the same custom face to every symbol on every page. Separate the brand-critical uses from routine reading. A distinctive heading may justify one font file while ordinary body text works better with a reliable system stack. Traditional Chinese commonly needs many more glyphs than a short English heading, so test real articles, addresses and product names rather than a few demonstration characters. If a subset lacks a character, the browser may mix faces within one line; inspect punctuation, numbers, English terms and Chinese text together. Keep the final decision visible to the content team. When a new campaign adds uncommon characters, staff need to know whether the chosen subset covers them and what fallback appears if it does not. This prevents a one-time launch review from becoming an assumption about all future copy.
Choose a visible loading behaviour
The font-display descriptor controls how a browser handles text while a web font is unavailable. A fallback can keep words visible, but a later swap can change line wrapping; a strategy that waits for the web font may preserve the intended face while delaying readable text. These are trade-offs to observe on the actual page. Google’s guidance discusses font-display alongside early loading and notes that early loading does not guarantee the font arrives before paint. For essential instructions and forms, prefer a path in which words are available promptly, then compare the visible result against the brand design. Do not treat a property name as an acceptance test. Test first load, repeat load and deliberately failed font requests; each can produce a different sequence of fonts and movement.
Make fallback deliberate
Fallback is part of the design system, not an emergency afterthought. Choose available fonts with similar proportions, line height and visual weight where possible, then check actual rendered lines in both locales. A fallback that is much wider can push a price onto a second line, enlarge a card, or move the primary action below the visible area. A very narrow face can make dense Chinese conditions harder to scan. Compare long product names, mixed English and Chinese addresses, large numerals and error summaries. Keep enough room around text and controls so a normal font change does not cause clipping. If layout shifts remain significant, revise the geometry or font choice rather than hiding content until the preferred file arrives. The relevant outcome is whether the customer can finish the task throughout loading.
Preload only a proven critical file
Preload can move a known font request earlier, but every early request competes for network capacity with other important resources. Google’s current font best-practices article warns that preloading should be used selectively. Identify the font face required by visible first-screen text on a specific template, confirm that the URL and format match the CSS declaration, and inspect the network waterfall. If the home page uses a different face from the product page, a blanket preload in a shared header may waste bandwidth. A Chinese page can also need different subsets from an English page. Start with no extra preload, measure a specific bottleneck, add the smallest useful request and compare. If it starts a duplicate download or delays the main image, remove or correct it. This is an engineering choice supported by observation, not a universal recipe.
Keep subsets honest
Subsetting is useful only when the split matches content that people actually see. A Latin-only file may be sufficient for English navigation, but it cannot supply every Traditional Chinese product name. Conversely, asking every visitor to download a full CJK face for a single decorative heading may be hard to justify. Use actual page copy and a representative list of names, punctuation, units and symbols to evaluate coverage. Test what happens when an unfamiliar character appears in a review or address. The browser’s automatic font selection should be checked visually because a technically correct fallback can still look uneven. If editorial staff publish new characters regularly, establish a repeatable subset build and visual spot check instead of freezing a one-off glyph list. Do not remove characters merely to hit an arbitrary file-size target.
Run a concrete bilingual test
Use one English product page and one Traditional Chinese page with comparable structure, then include a long article and a form. On a phone-sized viewport, clear the browser cache and record when headings, prices and controls become readable. Repeat with a slower connection and with the font request blocked. Watch the title, price, action and error area for line changes or clipping; take a short screen recording when a shift is difficult to describe. Check a repeat visit separately because cached files can hide first-visit problems. The purpose is to compare customer tasks, not to publish a made-up percentage improvement. Record the device, browser, route, language, network condition and observed problem, then attach the observation to the release decision. If your team uses a performance tool, interpret its output beside what people actually see.
Work through one release decision
Imagine an online shop whose English landing page looks polished, but its Chinese product page remains blank around the title while a large custom face downloads. A designer proposes preloading every font. A better review begins by identifying which file contains the visible Chinese title and whether the body already has a usable fallback. Remove unused weights, apply a deliberate display strategy and compare a system-font body against the custom body. If the title still arrives late, test a targeted preload on that template only. If the text becomes visible but the purchase button jumps, compare fallback metrics and card dimensions. Accept the release when the two languages remain usable under the tested conditions, and keep the screen recordings. This scenario is illustrative; it makes no claim about an actual shop or measured gain.
Assign ownership after launch
Font behaviour can change when a new campaign page, translation or CMS template introduces a different face. Put the chosen file list, fallback stack and any critical preload into a short release note. Give design responsibility for visual legibility, engineering responsibility for loading and deployment, and content responsibility for spotting new glyph needs. Recheck a sample page after a font or theme update and after a substantial Chinese content expansion. If customers report boxes, missing characters or jumping controls, capture the exact URL, device and text before changing the font globally. A local content error can require a different fix from a failed font request. The durable answer is a small, testable font system tied to real customer journeys, with enough evidence to tell which change helped.
Release checks
- Can a person complete the decision using the real page and a slow connection?
- Have staff tested the exceptional path and recorded who owns its repair?
