Веб-шрифты бренда: форматы, скорость загрузки, фолбэки
WOFF2 против остальных форматов: спор уже закончен
Технической дискуссии здесь почти не осталось. WOFF2 использует сжатие Brotli вместо Zlib у WOFF и даёт файл на 30% меньше при том же наборе глифов. По сравнению с необработанными TTF/OTF экономия доходит до 50-60%. Web.dev и сам Google Fonts прямо рекомендуют держать в проде только WOFF2 для современных браузеров — TTF/OTF имеет смысл оставлять лишь как крайний фолбэк для совсем старых сборок, если у бренда есть такая аудитория (для B2B и госсектора это иногда реально).
Вопрос, который стоит перед брендом на практике, звучит иначе: не «какой формат», а «сколько файлов формата» — обычный набор начертаний (Light, Regular, Medium, Bold, Italic) или один вариативный файл. Это отдельный раздел ниже.
Font-display: три стратегии — и они не взаимозаменяемы для разных типов контента
Разница между swap, fallback и optional — это не разница «быстрее/медленнее», а разница в философии: что важнее для конкретного блока бренда — мгновенный текст или стабильная картинка.
| Стратегия | Блокировка / окно замены | Когда использовать для бренда |
|---|---|---|
| swap | 0 мс блокировки, бесконечное окно замены | Основной текст, статьи, длинный контент — читаемость важнее визуальной идентичности в первую секунду |
| fallback | ~100 мс блокировки, ~3 сек окно замены | Логотип-текст, хедер, ключевые фирменные элементы — компромисс, когда бренд-шрифт важен, но не критичен |
| optional | ~100 мс блокировки, окно замены практически 0 | Второстепенные UI-элементы на медленных сетях — либо шрифт есть в кеше сразу, либо остаётся системный без последующей подмены |
Частая ошибка — ставить swap везде «по умолчанию», потому что так советует большинство гайдов. Для длинных текстовых страниц это оправдано. Но для главного экрана лендинга, где заголовок набран фирменным шрифтом и занимает половину высоты блока, swap даёт заметный jarring layout shift — заголовок дважды меняет размер и ломает верстку кнопок под ним. Здесь fallback честнее: он либо покажет фирменный шрифт быстро, либо через 3 секунды смирится с системным без нового скачка.
Фолбэк-стек: как подобрать замену, которая не «прыгает»
Главная причина layout shift при загрузке веб-шрифта — не сама загрузка, а разница метрик между фирменным шрифтом и его фолбэком: ширина символов, высота строки, положение базовой линии. Если фолбэк уже, чем бренд-шрифт, текст после подмены «раздувается» и сдвигает всё, что ниже.
Рабочий алгоритм подбора фолбэк-стека:
- Найти системный шрифт с похожей x-height и пропорциями ширины (для гротесков — Arial/Helvetica, для геометрических — часто ближе Segoe UI или системный sans-serif конкретной ОС).
- Прописать
font-metric overrides—ascent-override,descent-override,line-gap-override— так, чтобы метрики фолбэка математически совпали с фирменным шрифтом. - Добавить
size-adjust, если разница в ширине глифов остаётся даже после совпадения ascent/descent. - Проверить итог в Safari отдельно: он поддерживает только size-adjust и игнорирует override-свойства, поэтому стек, идеальный в Chrome, может всё равно сдвигаться в Safari — тестировать нужно в обоих движках.
Эта связка почти полностью убирает CLS от шрифтов, но она требует ручной калибровки под конкретную пару «бренд-шрифт — системный фолбэк», готового универсального рецепта не существует.
Subsetting для многоязычного бренда: латиница плюс кириллица не должны грузиться одним файлом
Для российского и восточноевропейского рынка типичная ошибка — тянуть полный шрифт со всеми диапазонами Unicode, хотя на конкретной странице используется либо латиница, либо кириллица, либо обе вперемешку в разных пропорциях.
- Latin (U+0000–00FF) как отдельный сабсет даёт экономию 70-90% от полного файла шрифта.
- Cyrillic (U+0400–04FF) как отдельный сабсет экономит 60-70%.
- Браузер через
unicode-rangeсам решает, какой файл грузить: если на странице нет кириллических символов, файл с кириллицей вообще не запрашивается.
Практический вывод для бренда с двумя языками на сайте: не делать один «универсальный» woff2 на все случаи, а резать шрифт минимум на два сабсета через unicode-range в @font-face, плюс отдельно — сабсет для цифр и пунктуации, если верстка агрессивно оптимизируется. Для бренда с кириллическим логотипом и латинским слоганом в одном блоке это не проблема — оба диапазона просто объявляются раздельно, и браузер запросит оба файла один раз, суммарно они всё равно легче монолитного шрифта.
Self-hosted или Google Fonts: алгоритм выбора, а не универсальный совет
Web Almanac показывает, что самостоятельный хостинг шрифтов на практике нередко медленнее Google Fonts — просто потому что у сайтов часто нет собственного CDN, HTTP/2 и грамотного кеширования. Но это не аргумент в пользу Google Fonts как такового, это аргумент в пользу инфраструктуры. При правильной настройке — CDN, preconnect к origin шрифта, длинный max-age в кеше — self-hosted обгоняет сторонний сервис, потому что убирает лишний DNS-lookup и TLS-handshake к чужому домену.
| Критерий | Google Fonts | Self-hosted |
|---|---|---|
| Скорость запуска | Быстро, без настройки | Требует CDN + кеш + preconnect |
| Контроль над идентичностью бренда | Ограничен — нет доступа к вариативным осям, метрикам, кастомным правкам | Полный — можно тонко настраивать unicode-range, metric overrides, вариативные оси |
| Зависимость от третьей стороны | Есть (домен fonts.googleapis.com, приватность, доступность) | Нет |
| Годится для | MVP, некоммерческие проекты, быстрый запуск | Зрелый бренд с собственным гайдлайном и кастомным/платным шрифтом |
Если у бренда лицензионный или кастомно нарисованный шрифт — самостоятельный хостинг обязателен, Google Fonts его физически не отдаёт. Если бренд использует шрифт из каталога Google Fonts «как есть» без модификаций — сервис вполне достаточен при условии, что добавлены preload и subsetting; штраф по LCP снимается именно этой парой настроек, а не сменой хостинга.
Variable Fonts: когда один файл выгоднее шести, а когда — нет
Вариативный шрифт заменяет 4-6 отдельных файлов (Light, Regular, Medium, Bold и так далее) одной осью веса, а иногда и осью ширины или наклона. При замене трёх статичных шрифтов на один вариативный с хорошей оптимизацией возможна экономия трафика и улучшение LCP (типичный выигрыш: 20-40% для трафика при 3+ начертаниях) — экономия ощутимая именно там, где бренд использует много начертаний одновременно: в карточках товара, ценах, бейджах.
Но выгода не универсальна. Если у бренда на сайте реально используются два начертания — Regular и Bold — вариативный файл может оказаться тяжелее суммы двух статичных woff2, потому что несёт в себе весь диапазон промежуточных значений веса, которые никто не запрашивает. Здесь работает простое правило:
- Три и более начертания на странице — вариативный шрифт почти всегда выигрывает по трафику и точно выигрывает по гибкости (можно плавно анимировать вес для интерактивных элементов бренда).
- Одно-два начертания — обычный статичный woff2 может быть легче и предсказуемее.
- Variable fonts поддерживаются всеми современными браузерами. Для старого Safari (до v10) и IE требуется статичный фолбэк через отдельный @font-face — без него бренд рискует получить либо не загруженный шрифт, либо сломанный рендер — без него бренд рискует получить сломанный рендер у части аудитории.
Как синхронизировать веб-версию шрифта с оффлайн гайдлайном бренда
Отдельная слепая зона у большинства гайдов — то, что веб-шрифт живёт своей жизнью отдельно от брендбука, и через год-два верстальщики используют системный фолбэк чаще, чем задумано дизайнером, просто потому что настройки font-display и подмены никто не аудирует. Практическое решение: зафиксировать в самом брендбуке не только «какой шрифт использовать», но и конкретные значения ascent-override/descent-override/size-adjust для официального фолбэк-стека, а также обязательную стратегию font-display для каждого типа блока (герой-баннер, основной текст, UI-элементы). Тогда веб-версия типографики бренда перестаёт быть черным ящиком для разработчиков и становится таким же регламентированным активом, как цвет или отступы в логотипе.
WOFF2 против остальных форматов: спор уже закончен
Технической дискуссии здесь почти не осталось. WOFF2 использует сжатие Brotli вместо Zlib у WOFF и даёт файл на 30% меньше при том же наборе глифов. По сравнению с необработанными TTF/OTF экономия доходит до 50-60%. Web.dev и сам Google Fonts прямо рекомендуют держать в проде только WOFF2 для современных браузеров — TTF/OTF имеет смысл оставлять лишь как крайний фолбэк для совсем старых сборок, если у бренда есть такая аудитория (для B2B и госсектора это иногда реально).
Вопрос, который стоит перед брендом на практике, звучит иначе: не «какой формат», а «сколько файлов формата» — обычный набор начертаний (Light, Regular, Medium, Bold, Italic) или один вариативный файл. Это отдельный раздел ниже.
Font-display: три стратегии — и они не взаимозаменяемы для разных типов контента
Разница между swap, fallback и optional — это не разница «быстрее/медленнее», а разница в философии: что важнее для конкретного блока бренда — мгновенный текст или стабильная картинка.
| Стратегия | Блокировка / окно замены | Когда использовать для бренда |
|---|---|---|
| swap | 0 мс блокировки, бесконечное окно замены | Основной текст, статьи, длинный контент — читаемость важнее визуальной идентичности в первую секунду |
| fallback | ~100 мс блокировки, ~3 сек окно замены | Логотип-текст, хедер, ключевые фирменные элементы — компромисс, когда бренд-шрифт важен, но не критичен |
| optional | ~100 мс блокировки, окно замены практически 0 | Второстепенные UI-элементы на медленных сетях — либо шрифт есть в кеше сразу, либо остаётся системный без последующей подмены |
Частая ошибка — ставить swap везде «по умолчанию», потому что так советует большинство гайдов. Для длинных текстовых страниц это оправдано. Но для главного экрана лендинга, где заголовок набран фирменным шрифтом и занимает половину высоты блока, swap даёт заметный jarring layout shift — заголовок дважды меняет размер и ломает верстку кнопок под ним. Здесь fallback честнее: он либо покажет фирменный шрифт быстро, либо через 3 секунды смирится с системным без нового скачка.
Фолбэк-стек: как подобрать замену, которая не «прыгает»
Главная причина layout shift при загрузке веб-шрифта — не сама загрузка, а разница метрик между фирменным шрифтом и его фолбэком: ширина символов, высота строки, положение базовой линии. Если фолбэк уже, чем бренд-шрифт, текст после подмены «раздувается» и сдвигает всё, что ниже.
Рабочий алгоритм подбора фолбэк-стека:
- Найти системный шрифт с похожей x-height и пропорциями ширины (для гротесков — Arial/Helvetica, для геометрических — часто ближе Segoe UI или системный sans-serif конкретной ОС).
- Прописать
font-metric overrides—ascent-override,descent-override,line-gap-override— так, чтобы метрики фолбэка математически совпали с фирменным шрифтом. - Добавить
size-adjust, если разница в ширине глифов остаётся даже после совпадения ascent/descent. - Проверить итог в Safari отдельно: он поддерживает только size-adjust и игнорирует override-свойства, поэтому стек, идеальный в Chrome, может всё равно сдвигаться в Safari — тестировать нужно в обоих движках.
Эта связка почти полностью убирает CLS от шрифтов, но она требует ручной калибровки под конкретную пару «бренд-шрифт — системный фолбэк», готового универсального рецепта не существует.
Subsetting для многоязычного бренда: латиница плюс кириллица не должны грузиться одним файлом
Для российского и восточноевропейского рынка типичная ошибка — тянуть полный шрифт со всеми диапазонами Unicode, хотя на конкретной странице используется либо латиница, либо кириллица, либо обе вперемешку в разных пропорциях.
- Latin (U+0000–00FF) как отдельный сабсет даёт экономию 70-90% от полного файла шрифта.
- Cyrillic (U+0400–04FF) как отдельный сабсет экономит 60-70%.
- Браузер через
unicode-rangeсам решает, какой файл грузить: если на странице нет кириллических символов, файл с кириллицей вообще не запрашивается.
Практический вывод для бренда с двумя языками на сайте: не делать один «универсальный» woff2 на все случаи, а резать шрифт минимум на два сабсета через unicode-range в @font-face, плюс отдельно — сабсет для цифр и пунктуации, если верстка агрессивно оптимизируется. Для бренда с кириллическим логотипом и латинским слоганом в одном блоке это не проблема — оба диапазона просто объявляются раздельно, и браузер запросит оба файла один раз, суммарно они всё равно легче монолитного шрифта.
Self-hosted или Google Fonts: алгоритм выбора, а не универсальный совет
Web Almanac показывает, что самостоятельный хостинг шрифтов на практике нередко медленнее Google Fonts — просто потому что у сайтов часто нет собственного CDN, HTTP/2 и грамотного кеширования. Но это не аргумент в пользу Google Fonts как такового, это аргумент в пользу инфраструктуры. При правильной настройке — CDN, preconnect к origin шрифта, длинный max-age в кеше — self-hosted обгоняет сторонний сервис, потому что убирает лишний DNS-lookup и TLS-handshake к чужому домену.
| Критерий | Google Fonts | Self-hosted |
|---|---|---|
| Скорость запуска | Быстро, без настройки | Требует CDN + кеш + preconnect |
| Контроль над идентичностью бренда | Ограничен — нет доступа к вариативным осям, метрикам, кастомным правкам | Полный — можно тонко настраивать unicode-range, metric overrides, вариативные оси |
| Зависимость от третьей стороны | Есть (домен fonts.googleapis.com, приватность, доступность) | Нет |
| Годится для | MVP, некоммерческие проекты, быстрый запуск | Зрелый бренд с собственным гайдлайном и кастомным/платным шрифтом |
Если у бренда лицензионный или кастомно нарисованный шрифт — самостоятельный хостинг обязателен, Google Fonts его физически не отдаёт. Если бренд использует шрифт из каталога Google Fonts «как есть» без модификаций — сервис вполне достаточен при условии, что добавлены preload и subsetting; штраф по LCP снимается именно этой парой настроек, а не сменой хостинга.
Variable Fonts: когда один файл выгоднее шести, а когда — нет
Вариативный шрифт заменяет 4-6 отдельных файлов (Light, Regular, Medium, Bold и так далее) одной осью веса, а иногда и осью ширины или наклона. При замене трёх статичных шрифтов на один вариативный с хорошей оптимизацией возможна экономия трафика и улучшение LCP (типичный выигрыш: 20-40% для трафика при 3+ начертаниях) — экономия ощутимая именно там, где бренд использует много начертаний одновременно: в карточках товара, ценах, бейджах.
Но выгода не универсальна. Если у бренда на сайте реально используются два начертания — Regular и Bold — вариативный файл может оказаться тяжелее суммы двух статичных woff2, потому что несёт в себе весь диапазон промежуточных значений веса, которые никто не запрашивает. Здесь работает простое правило:
- Три и более начертания на странице — вариативный шрифт почти всегда выигрывает по трафику и точно выигрывает по гибкости (можно плавно анимировать вес для интерактивных элементов бренда).
- Одно-два начертания — обычный статичный woff2 может быть легче и предсказуемее.
- Variable fonts поддерживаются всеми современными браузерами. Для старого Safari (до v10) и IE требуется статичный фолбэк через отдельный @font-face — без него бренд рискует получить либо не загруженный шрифт, либо сломанный рендер — без него бренд рискует получить сломанный рендер у части аудитории.
Как синхронизировать веб-версию шрифта с оффлайн гайдлайном бренда
Отдельная слепая зона у большинства гайдов — то, что веб-шрифт живёт своей жизнью отдельно от брендбука, и через год-два верстальщики используют системный фолбэк чаще, чем задумано дизайнером, просто потому что настройки font-display и подмены никто не аудирует. Практическое решение: зафиксировать в самом брендбуке не только «какой шрифт использовать», но и конкретные значения ascent-override/descent-override/size-adjust для официального фолбэк-стека, а также обязательную стратегию font-display для каждого типа блока (герой-баннер, основной текст, UI-элементы). Тогда веб-версия типографики бренда перестаёт быть черным ящиком для разработчиков и становится таким же регламентированным активом, как цвет или отступы в логотипе.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
