Reduce the font work each route asks the browser to do
Inventory cold-cache font requests on the home page, conversion pages, logged-in views, and templates with different design systems. Note the family, weight, style, file, origin, transfer size, and selector. A declared @font-face rule does not by itself trigger a download; a browser normally fetches a face when the current layout uses it. That makes unused global weights and styles worth removing first.
Use custom type where it carries real brand value, often in display headings, and consider a system stack for ordinary body copy when the design allows it. Do not assume a variable font is always smaller: it can replace several static files but may be larger than one static face. Compare the compressed assets actually requested by the route.
Remove families, weights, italics, and icon fonts that have no tested route-level use.
Check that the license permits web delivery, subsetting, and self-hosting before changing the build.
Use WOFF2 and subset without removing needed characters
Start with WOFF2 for a modern-browser baseline. The W3C Recommendation describes WOFF2 as a web-font package designed for improved compression and fast decompression, and it is implemented in major browsers. Keep another format only for a documented legacy-browser requirement; otherwise a well-designed fallback is the safer compatibility path.
Subsetting creates a smaller file containing selected glyphs, or character shapes. Unicode-range can associate subsets with character ranges so the browser chooses a relevant file while matching text. Build subsets from real pages and the languages you support, including punctuation, currencies, names, legal text, and user-entered scripts. Missing glyphs are a correctness problem, not an acceptable byte saving.
Test representative localized pages and form input, not just English design samples.
Ensure each subset’s unicode-range and weight/style range matches the deployed file.
Design the fallback and font-display policy together
A fallback font is what users see when the custom face is not ready. Choose it for similar proportions, then compare real headings, multi-line buttons, navigation, tables, forms, and long localized strings. Different widths change wrapping; different ascent, descent, or line gap changes block height. Both can move content already visible on the page.
font-display defines rendering behavior while a face is unavailable. Optional has an extremely small block period and no swap period, so it can suit body text when stable fallback is preferable on the first visit. Swap shows fallback promptly and can later apply the web font, but only use it where a late replacement will not cause a disruptive reflow. Block or fallback should serve a tested design reason, not be a global default. CSS size-adjust can help tune a fallback’s metrics, but verify each supported script and viewport visually.
Do not make payment, recovery, account, safety, or navigation text depend on a late custom font.
A fallback letter can convey the wrong meaning; SVG icons are generally safer for interface symbols.
Improve discovery, but restrain preload and assess data flow
A face declared only in an external stylesheet may be discovered after that stylesheet downloads and parses. Maintainable early critical CSS can expose a necessary declaration sooner; do not inline the font binary, which enlarges the document. For a third-party origin, preconnect may establish the connection earlier. Font requests are CORS resources, so cross-origin delivery and preloads require correct crossorigin handling.
Preload is a priority override, not a blanket speed switch. It can compete with other critical work and can download a face a route never needs; it also bypasses unicode-range selection. Fix late discovery first, then preload at most one proven first-view file using the exact URL, as=font, and crossorigin. Google Fonts says API requests include the visitor IP address, requested URL, HTTP headers, and referer; it also says its API does not set or log cookies and does not use collected information for profiles or targeted advertising. Self-hosting stops Google receiving data for those loads. Evaluate delivery, privacy notice, jurisdiction, contracts, and qualified advice where needed.
Compare cold-cache traces and confirm the preloaded file is consumed on the route.
Weigh connection setup, cache and CDN capability, asset maintenance, and visitor-data flow.
Version font assets and retain a tested CSS fallback configuration.
Test rendered behavior and operate fonts as a resilience dependency
With a cold cache, use browser network tools to inspect the CSS-to-font request chain, timing, origin, caching, and failures. Repeat on a constrained connection, then throttle or block the font. Success means readable text, usable controls, accurate symbols, and coherent layout before the custom face appears. Test realistic narrow and desktop layouts, long strings, errors, consent copy, prices, and every supported script.
In Chromium, record a reload in the Performance panel and inspect the Layout Shifts track; DevTools can identify moved elements and animate the shift. Font loading is a known culprit, but a moved element is not necessarily the root cause, so correlate the trace with the font application. The Layout Instability API is Chromium-only, which makes cross-browser visual checks important. Include font assets, CORS behavior, cache policy, fallbacks, and rollback in release review. The intended degraded mode is readable text, not blank content or broken navigation.
A warm cache can conceal the initial request and rendering problem.
Repeat the check when files, CMS copy, templates, providers, or CDN rules change.