Дизайнер сдаёт макет с фирменным шрифтом, разработчик подключает Google Fonts — и страница внезапно проседает по LCP. Это не редкость: шрифты от Google Fonts стоят на примерно 43% сайтов в интернете, и на мобильных устройствах они снижают долю «хороших» LCP-показателей с 72,3% до 63,0% — почти на 9,3 пункта. Общий проход Core Web Vitals падает с 43,9% до 40,3%. Цифры небольшие в абсолютном выражении, но на масштабе трафика они превращаются в реальные потери конверсии и позиций в поиске.
Проблема усугубляется тем, как браузеры ведут себя при загрузке шрифта. Chromium и Firefox блокируют отрисовку текста максимум на 3 секунды, а затем показывают fallback. Safari же способен ждать бесконечно, если не задать поведение явно через font-display. То есть без настройки один и тот же сайт в Safari может показывать пустой экран дольше, чем в Chrome — это чисто техническая деталь, которая часто выпадает из брифов на дизайн.
Многие путают font-family: system-ui с классическим стеком вроде того, что использует GitHub и Medium: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif. Разница принципиальная.
| Параметр | system-ui | Явный стек (GitHub/Medium) |
|---|---|---|
| Совместимость со старыми браузерами | Хуже — не поддерживается в старых версиях Edge и части Android WebView | Лучше — покрывает больше окружений явными именами |
| Предсказуемость начертания | Отдаёт системный UI-шрифт, который может отличаться от «обычного» текстового шрифта ОС | Позволяет явно указать желаемый шрифт для каждой платформы |
| Объём кода | Одно ключевое слово | Длинная строка, требует поддержки и обновления |
| Когда использовать | Быстрые прототипы, внутренние инструменты | Продакшн-интерфейсы, где важна стабильность на всех ОС |
На практике для продакшена лучше явный список: он предсказуемее и не преподносит сюрпризов, когда Google в очередной раз меняет поведение system-ui в Chrome.
Ошибка большинства гибридных решений в том, что их описывают абстрактно — «заголовки веб-шрифтом, текст системным» — без привязки к типу продукта. На деле граница проходит по-разному в зависимости от интерфейса.
| Тип интерфейса | Веб-шрифт (бренд) | Системный шрифт |
|---|---|---|
| SaaS-дашборд | Логотип, название продукта в шапке | Все кнопки, таблицы, формы, навигация, тексты уведомлений |
| Маркетинговый сайт / лендинг | H1, H2, хайлайты, цитаты, крупные цифры в блоках преимуществ | Основной текст, футер, юридические блоки |
| E-commerce | Название бренда, заголовки категорий, крупные промо-баннеры | Цена, кнопка «Купить», характеристики товара, фильтры |
Логика простая: элементы, влияющие на LCP (обычно это первый экран с текстом карточек, ценами или основным контентом), почти всегда лучше оставить на системном шрифте. Заголовки страницы редко являются LCP-элементом — значит, веб-шрифт на них не штрафует метрику. При такой раскладке на страницу достаточно одного файла WOFF2 весом 30–50 КБ вместо полной семьи в 150–240 КБ. WOFF2 к тому же сжимает данные на 30% лучше формата WOFF за счёт алгоритма Brotli — если у вас ещё используется старый формат, это первое, что стоит поменять.
Выбор значения зависит не от «вкуса», а от типа страницы и от того, что критичнее — стабильность вида или отсутствие визуального дребезга.
Практическое правило: заголовки на маркетинговом сайте — swap, элементы UI в продукте, если вы всё же решили пустить туда веб-шрифт — optional.
Даже без веб-шрифтов сдвиги возможны — SF Pro на macOS, Segoe UI на Windows и Roboto на Android имеют разную высоту строки, и в однострочных элементах вроде кнопок или бейджей это даёт разброс в 1-2 пикселя между платформами. При добавлении веб-шрифта разброс увеличивается, потому что метрики брендового шрифта и fallback-шрифта почти никогда не совпадают идеально.
Решается это не отказом от веб-шрифта, а точной настройкой CSS-дескрипторов внутри @font-face:
size-adjust, чтобы масштабировать fallback-шрифт под кегль брендового — это убирает разницу в занимаемой ширине текста.ascent-override, descent-override и line-gap-override, чтобы выровнять высоту строки fallback-шрифта с реальными метриками бренд-шрифта.Эта настройка занимает час работы фронтендера, но убирает визуальный «прыжок» почти полностью — без отказа от бренд-шрифта и без ухудшения LCP.
Первая и самая дорогая ошибка — подключать всю шрифтовую семью «на будущее»: обычный, курсив, полужирный, экстраболд по 30-50 КБ каждый, хотя реально используется два начертания. Это добавляет сотни килобайт без видимой выгоды.
Вторая ошибка — ставить font-display: block по умолчанию, потому что «так надёжнее для бренда». На деле это худший вариант для Safari, где блокировка становится почти бесконечной без явного тайм-аута.
Третья — использовать веб-шрифт для текста в карточках товаров или таблицах данных. Такой текст обычно совпадает с LCP-элементом, и именно здесь производительность бьёт по продажам сильнее всего.
Итоговая рекомендация для SaaS и большинства цифровых продуктов: система — для всего UI (кнопки, формы, навигация, таблицы), один бренд-шрифт — для логотипа и крупных заголовков. Такая связка минимизирует и CLS, и LCP одновременно, оставляя бренду ровно то визуальное присутствие, которое действительно работает на узнаваемость.
Дизайнер сдаёт макет с фирменным шрифтом, разработчик подключает Google Fonts — и страница внезапно проседает по LCP. Это не редкость: шрифты от Google Fonts стоят на примерно 43% сайтов в интернете, и на мобильных устройствах они снижают долю «хороших» LCP-показателей с 72,3% до 63,0% — почти на 9,3 пункта. Общий проход Core Web Vitals падает с 43,9% до 40,3%. Цифры небольшие в абсолютном выражении, но на масштабе трафика они превращаются в реальные потери конверсии и позиций в поиске.
Проблема усугубляется тем, как браузеры ведут себя при загрузке шрифта. Chromium и Firefox блокируют отрисовку текста максимум на 3 секунды, а затем показывают fallback. Safari же способен ждать бесконечно, если не задать поведение явно через font-display. То есть без настройки один и тот же сайт в Safari может показывать пустой экран дольше, чем в Chrome — это чисто техническая деталь, которая часто выпадает из брифов на дизайн.
Многие путают font-family: system-ui с классическим стеком вроде того, что использует GitHub и Medium: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif. Разница принципиальная.
| Параметр | system-ui | Явный стек (GitHub/Medium) |
|---|---|---|
| Совместимость со старыми браузерами | Хуже — не поддерживается в старых версиях Edge и части Android WebView | Лучше — покрывает больше окружений явными именами |
| Предсказуемость начертания | Отдаёт системный UI-шрифт, который может отличаться от «обычного» текстового шрифта ОС | Позволяет явно указать желаемый шрифт для каждой платформы |
| Объём кода | Одно ключевое слово | Длинная строка, требует поддержки и обновления |
| Когда использовать | Быстрые прототипы, внутренние инструменты | Продакшн-интерфейсы, где важна стабильность на всех ОС |
На практике для продакшена лучше явный список: он предсказуемее и не преподносит сюрпризов, когда Google в очередной раз меняет поведение system-ui в Chrome.
Ошибка большинства гибридных решений в том, что их описывают абстрактно — «заголовки веб-шрифтом, текст системным» — без привязки к типу продукта. На деле граница проходит по-разному в зависимости от интерфейса.
| Тип интерфейса | Веб-шрифт (бренд) | Системный шрифт |
|---|---|---|
| SaaS-дашборд | Логотип, название продукта в шапке | Все кнопки, таблицы, формы, навигация, тексты уведомлений |
| Маркетинговый сайт / лендинг | H1, H2, хайлайты, цитаты, крупные цифры в блоках преимуществ | Основной текст, футер, юридические блоки |
| E-commerce | Название бренда, заголовки категорий, крупные промо-баннеры | Цена, кнопка «Купить», характеристики товара, фильтры |
Логика простая: элементы, влияющие на LCP (обычно это первый экран с текстом карточек, ценами или основным контентом), почти всегда лучше оставить на системном шрифте. Заголовки страницы редко являются LCP-элементом — значит, веб-шрифт на них не штрафует метрику. При такой раскладке на страницу достаточно одного файла WOFF2 весом 30–50 КБ вместо полной семьи в 150–240 КБ. WOFF2 к тому же сжимает данные на 30% лучше формата WOFF за счёт алгоритма Brotli — если у вас ещё используется старый формат, это первое, что стоит поменять.
Выбор значения зависит не от «вкуса», а от типа страницы и от того, что критичнее — стабильность вида или отсутствие визуального дребезга.
Практическое правило: заголовки на маркетинговом сайте — swap, элементы UI в продукте, если вы всё же решили пустить туда веб-шрифт — optional.
Даже без веб-шрифтов сдвиги возможны — SF Pro на macOS, Segoe UI на Windows и Roboto на Android имеют разную высоту строки, и в однострочных элементах вроде кнопок или бейджей это даёт разброс в 1-2 пикселя между платформами. При добавлении веб-шрифта разброс увеличивается, потому что метрики брендового шрифта и fallback-шрифта почти никогда не совпадают идеально.
Решается это не отказом от веб-шрифта, а точной настройкой CSS-дескрипторов внутри @font-face:
size-adjust, чтобы масштабировать fallback-шрифт под кегль брендового — это убирает разницу в занимаемой ширине текста.ascent-override, descent-override и line-gap-override, чтобы выровнять высоту строки fallback-шрифта с реальными метриками бренд-шрифта.Эта настройка занимает час работы фронтендера, но убирает визуальный «прыжок» почти полностью — без отказа от бренд-шрифта и без ухудшения LCP.
Первая и самая дорогая ошибка — подключать всю шрифтовую семью «на будущее»: обычный, курсив, полужирный, экстраболд по 30-50 КБ каждый, хотя реально используется два начертания. Это добавляет сотни килобайт без видимой выгоды.
Вторая ошибка — ставить font-display: block по умолчанию, потому что «так надёжнее для бренда». На деле это худший вариант для Safari, где блокировка становится почти бесконечной без явного тайм-аута.
Третья — использовать веб-шрифт для текста в карточках товаров или таблицах данных. Такой текст обычно совпадает с LCP-элементом, и именно здесь производительность бьёт по продажам сильнее всего.
Итоговая рекомендация для SaaS и большинства цифровых продуктов: система — для всего UI (кнопки, формы, навигация, таблицы), один бренд-шрифт — для логотипа и крупных заголовков. Такая связка минимизирует и CLS, и LCP одновременно, оставляя бренду ровно то визуальное присутствие, которое действительно работает на узнаваемость.