Brand web fonts: formats, loading speed, fallbacks
WOFF2 versus other formats: the debate is over
There is almost no technical discussion left here. WOFF2 uses Brotli compression instead of Zlib in WOFF and gives a file that is 30% smaller with the same set of glyphs. Compared to raw TTF/OTF, the savings can reach 50-60%. Web.dev and Google Fonts itself recommend keeping only WOFF2 in production for modern browsers — TTF/OTF only makes sense as a last resort for very old builds, if the brand has such an audience (for B2B and the public sector, this is sometimes real).
The question that brands face in practice is different: not 'which format', but 'how many format files' — a standard set of typefaces (Light, Regular, Medium, Bold, Italic) or one variable file. This is a separate section below.
Font-display: three strategies — and they are not interchangeable for different types of content
The difference between swap, fallback and optional is not a difference between 'faster/slower', but a difference in philosophy: what is more important for a specific brand block — instant text or a stable image.
| Strategy | Blocking / replacement window | When to use for a brand |
|---|---|---|
| swap | 0 ms blocking, infinite replacement window | Main text, articles, long content — readability is more important than visual identity in the first second |
| fallback | ~100 ms blocking, ~3 sec replacement window | Logo-text, header, key brand elements — a compromise when brand font is important but not critical |
| optional | ~100 ms blocking, replacement window practically 0 | Secondary UI elements on slow networks — either the font is in the cache immediately, or the system font remains without subsequent replacement |
A common mistake is to set swap everywhere 'by default', because most guides recommend it. This is justified for long text pages. But for the main landing screen, where the heading is in the brand font and takes up half the block height, swap causes a noticeable jarring layout shift — the heading changes size twice and breaks the button layout below. Here, fallback is fairer: it will either show the brand font quickly, or after 3 seconds resign itself to the system font without a new jump.
Fallback stack: how to choose a replacement that doesn't 'jump'
The main cause of layout shift when loading a web font is not the load itself, but the difference in metrics between the brand font and its fallback: character width, line height, baseline position. If the fallback is narrower than the brand font, the text after replacement 'puffs up' and shifts everything below.
Working algorithm for selecting a fallback stack:
- Find a system font with a similar x-height and width proportions (for grotesque fonts — Arial/Helvetica, for geometric fonts — often closer to Segoe UI or the OS-specific sans-serif).
- Specify
font-metric overrides—ascent-override,descent-override,line-gap-override— so that the fallback metrics mathematically match the brand font. - Add
size-adjust, if the difference in glyph width remains even after matching ascent/descent. - Check the result in Safari separately: it only supports size-adjust and ignores override properties, so a stack that is ideal in Chrome may still shift in Safari — testing in both engines is necessary.
This combination almost completely eliminates CLS from fonts, but it requires manual calibration for a specific 'brand font — system fallback' pair; there is no ready-made universal recipe.
Subsetting for a multilingual brand: Latin plus Cyrillic should not be loaded in a single file
For the Russian and East-European markets, a typical mistake is to load the full font with all Unicode ranges, whereas on a specific page only Latin, or Cyrillic, or both in varying proportions are used
- Latin (U+0000–00FF) as a separate subset provides a 70-90% saving on the full font file
- Cyrillic (U+0400–04FF) as a separate subset saves 60-70%
- The browser via
unicode-rangeitself decides which file to load: if there are no Cyrillic characters on the page, the file with Cyrillic is not requested at all
Practical takeaway for a brand with two languages on the site: do not make one 'universal' woff2 for all cases, but slice the font into at least two subsets via unicode-range in @font-face, plus separately — a subset for digits and punctuation, if the layout is aggressively optimized. For a brand with a Cyrillic logo and a Latin slogan in one block, this is not a problem — both ranges are simply declared separately, and the browser will request both files once, and they will still be lighter combined than a monolithic font.
Self-hosted or Google Fonts: selection algorithm, not a universal advice
Web Almanac shows that self-hosted font hosting in practice is often slower than Google Fonts — simply because sites often lack their own CDN, HTTP/2 and proper caching. But this is not an argument in favor of Google Fonts per se, it is an argument in favor of infrastructure. With proper setup — CDN, preconnect to the font origin, long max-age in cache — self-hosted outperforms external services, because it removes the extra DNS-lookup and TLS-handshake to a foreign domain.
| Criterion | Google Fonts | Self-hosted |
|---|---|---|
| Launch speed | Fast, no setup required | Requires CDN + cache + preconnect |
| Control over brand identity | Limited — no access to variable axes, metrics, custom tweaks | Full — can finely tune unicode-range, metric overrides, variable axes |
| Dependency on a third party | Exists (fonts.googleapis.com domain, privacy, availability) | No |
| Suitable for | MVP, non-commercial projects, fast launch | Mature brand with its own guideline and custom/paid font |
If a brand has a licensed or custom-drawn font, independent hosting is mandatory, as Google Fonts does not physically serve it. If a brand uses a font from the Google Fonts catalog 'as is' without modifications, the service is quite sufficient, provided that preload and subsetting are added; the LCP penalty is removed precisely by this pair of settings, not by changing the hosting.
Variable Fonts: when one file is more advantageous than six, and when it is not
A variable font replaces 4-6 individual files (Light, Regular, Medium, Bold, and so on) along a single weight axis, and sometimes even a width or slant axis. Replacing three static fonts with one variable font with good optimization can result in traffic savings and improved LCP (typical gain: 20-40% for traffic with 3+ variations) — the savings are noticeable precisely where a brand uses many variations simultaneously: in product cards, prices, badges.
But the benefit is not universal. If a brand actually uses only two variations on its website — Regular and Bold — a variable font file may end up heavier than the sum of two static woff2 files, because it contains the entire range of intermediate weight values that nobody requests. Here a simple rule applies:
- Three or more variations on a page — a variable font almost always wins in terms of traffic and definitely wins in flexibility (you can smoothly animate weight for interactive brand elements).
- One or two variations — a regular static woff2 file may be lighter and more predictable.
- Variable fonts are supported by all modern browsers. For older Safari (up to v10) and IE, a static fallback via a separate @font-face is required — without it, a brand risks either a non-loaded font or a broken render — without it, a brand risks broken rendering for part of its audience.
How to synchronize the web version of the font with the offline brand guideline
A separate blind spot in most guidelines is that the web font lives its own life separate from the brand book, and within a year or two, developers will use the system fallback more than intended by the designer, simply because no one audits the font-display settings and font substitution. Practical solution: fix in the brand book itself not only 'which font to use,' but also the specific values of ascent-override/descent-override/size-adjust for the official fallback stack, as well as the mandatory font-display strategy for each type of block (hero banner, main text, UI elements). That way, the web version of the brand's typography stops being a black box for developers and becomes a similarly regulated asset as color or spacing in the logo.
WOFF2 versus other formats: the debate is over
There is almost no technical discussion left here. WOFF2 uses Brotli compression instead of Zlib in WOFF and gives a file that is 30% smaller with the same set of glyphs. Compared to raw TTF/OTF, the savings can reach 50-60%. Web.dev and Google Fonts itself recommend keeping only WOFF2 in production for modern browsers — TTF/OTF only makes sense as a last resort for very old builds, if the brand has such an audience (for B2B and the public sector, this is sometimes real).
The question that brands face in practice is different: not 'which format', but 'how many format files' — a standard set of typefaces (Light, Regular, Medium, Bold, Italic) or one variable file. This is a separate section below.
Font-display: three strategies — and they are not interchangeable for different types of content
The difference between swap, fallback and optional is not a difference between 'faster/slower', but a difference in philosophy: what is more important for a specific brand block — instant text or a stable image.
| Strategy | Blocking / replacement window | When to use for a brand |
|---|---|---|
| swap | 0 ms blocking, infinite replacement window | Main text, articles, long content — readability is more important than visual identity in the first second |
| fallback | ~100 ms blocking, ~3 sec replacement window | Logo-text, header, key brand elements — a compromise when brand font is important but not critical |
| optional | ~100 ms blocking, replacement window practically 0 | Secondary UI elements on slow networks — either the font is in the cache immediately, or the system font remains without subsequent replacement |
A common mistake is to set swap everywhere 'by default', because most guides recommend it. This is justified for long text pages. But for the main landing screen, where the heading is in the brand font and takes up half the block height, swap causes a noticeable jarring layout shift — the heading changes size twice and breaks the button layout below. Here, fallback is fairer: it will either show the brand font quickly, or after 3 seconds resign itself to the system font without a new jump.
Fallback stack: how to choose a replacement that doesn't 'jump'
The main cause of layout shift when loading a web font is not the load itself, but the difference in metrics between the brand font and its fallback: character width, line height, baseline position. If the fallback is narrower than the brand font, the text after replacement 'puffs up' and shifts everything below.
Working algorithm for selecting a fallback stack:
- Find a system font with a similar x-height and width proportions (for grotesque fonts — Arial/Helvetica, for geometric fonts — often closer to Segoe UI or the OS-specific sans-serif).
- Specify
font-metric overrides—ascent-override,descent-override,line-gap-override— so that the fallback metrics mathematically match the brand font. - Add
size-adjust, if the difference in glyph width remains even after matching ascent/descent. - Check the result in Safari separately: it only supports size-adjust and ignores override properties, so a stack that is ideal in Chrome may still shift in Safari — testing in both engines is necessary.
This combination almost completely eliminates CLS from fonts, but it requires manual calibration for a specific 'brand font — system fallback' pair; there is no ready-made universal recipe.
Subsetting for a multilingual brand: Latin plus Cyrillic should not be loaded in a single file
For the Russian and East-European markets, a typical mistake is to load the full font with all Unicode ranges, whereas on a specific page only Latin, or Cyrillic, or both in varying proportions are used
- Latin (U+0000–00FF) as a separate subset provides a 70-90% saving on the full font file
- Cyrillic (U+0400–04FF) as a separate subset saves 60-70%
- The browser via
unicode-rangeitself decides which file to load: if there are no Cyrillic characters on the page, the file with Cyrillic is not requested at all
Practical takeaway for a brand with two languages on the site: do not make one 'universal' woff2 for all cases, but slice the font into at least two subsets via unicode-range in @font-face, plus separately — a subset for digits and punctuation, if the layout is aggressively optimized. For a brand with a Cyrillic logo and a Latin slogan in one block, this is not a problem — both ranges are simply declared separately, and the browser will request both files once, and they will still be lighter combined than a monolithic font.
Self-hosted or Google Fonts: selection algorithm, not a universal advice
Web Almanac shows that self-hosted font hosting in practice is often slower than Google Fonts — simply because sites often lack their own CDN, HTTP/2 and proper caching. But this is not an argument in favor of Google Fonts per se, it is an argument in favor of infrastructure. With proper setup — CDN, preconnect to the font origin, long max-age in cache — self-hosted outperforms external services, because it removes the extra DNS-lookup and TLS-handshake to a foreign domain.
| Criterion | Google Fonts | Self-hosted |
|---|---|---|
| Launch speed | Fast, no setup required | Requires CDN + cache + preconnect |
| Control over brand identity | Limited — no access to variable axes, metrics, custom tweaks | Full — can finely tune unicode-range, metric overrides, variable axes |
| Dependency on a third party | Exists (fonts.googleapis.com domain, privacy, availability) | No |
| Suitable for | MVP, non-commercial projects, fast launch | Mature brand with its own guideline and custom/paid font |
If a brand has a licensed or custom-drawn font, independent hosting is mandatory, as Google Fonts does not physically serve it. If a brand uses a font from the Google Fonts catalog 'as is' without modifications, the service is quite sufficient, provided that preload and subsetting are added; the LCP penalty is removed precisely by this pair of settings, not by changing the hosting.
Variable Fonts: when one file is more advantageous than six, and when it is not
A variable font replaces 4-6 individual files (Light, Regular, Medium, Bold, and so on) along a single weight axis, and sometimes even a width or slant axis. Replacing three static fonts with one variable font with good optimization can result in traffic savings and improved LCP (typical gain: 20-40% for traffic with 3+ variations) — the savings are noticeable precisely where a brand uses many variations simultaneously: in product cards, prices, badges.
But the benefit is not universal. If a brand actually uses only two variations on its website — Regular and Bold — a variable font file may end up heavier than the sum of two static woff2 files, because it contains the entire range of intermediate weight values that nobody requests. Here a simple rule applies:
- Three or more variations on a page — a variable font almost always wins in terms of traffic and definitely wins in flexibility (you can smoothly animate weight for interactive brand elements).
- One or two variations — a regular static woff2 file may be lighter and more predictable.
- Variable fonts are supported by all modern browsers. For older Safari (up to v10) and IE, a static fallback via a separate @font-face is required — without it, a brand risks either a non-loaded font or a broken render — without it, a brand risks broken rendering for part of its audience.
How to synchronize the web version of the font with the offline brand guideline
A separate blind spot in most guidelines is that the web font lives its own life separate from the brand book, and within a year or two, developers will use the system fallback more than intended by the designer, simply because no one audits the font-display settings and font substitution. Practical solution: fix in the brand book itself not only 'which font to use,' but also the specific values of ascent-override/descent-override/size-adjust for the official fallback stack, as well as the mandatory font-display strategy for each type of block (hero banner, main text, UI elements). That way, the web version of the brand's typography stops being a black box for developers and becomes a similarly regulated asset as color or spacing in the logo.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
