✦Первый в России сайт с полным циклом ИИ✦Смотрите презентацию ИИ-сайта продаж✦Сайт, которым полностью управляет ИИ✦Контент, реклама, лиды и аналитика — на автопилоте
Собрать игру

Оптимизация шрифтов для снижения CLS

12 мин чтения
С

Сергей и ЛеонидВедущий специалист по CRM AmSales

Внедряет Битрикс24 и amoCRM, автоматизирует продажи и бизнес-процессы. Золотой партнёр Битрикс24, 400+ проектов.

Оптимизация шрифтов для снижения CLS

Коротко: Чтобы снизить CLS (Cumulative Layout Shift), необходимо минимизировать визуальные скачки при загрузке шрифтов. Основные методы включают использование формата WOFF2, самохостинг, предварительную загрузку (preload) критических начертаний и применение метрических оверрайдов (ascent/descent override) для выравнивания размеров системного шрифта с основным. Для максимальной стабильности верстки на медленных сетях рекомендуется использовать свойство font-display: optional.

Кстати, в AmSales мы делаем разработку сайтов под ключ и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Что такое CLS и как шрифты портят метрики

Cumulative Layout Shift (CLS) - это метрика, которая измеряет визуальную стабильность страницы. Она показывает, насколько часто элементы контента «прыгают» во время загрузки сайта. Если пользователь собирается нажать на кнопку, а в этот момент сверху подгружается текст, написанный необычным шрифтом, и вся верстка съезжает вниз - это плохой CLS. Для современных поисковых систем и Google, это критический показатель качества UX. Согласно актуальным стандартам, значение CLS ниже 0.1 считается отличным (Good), а если показатель превышает 0.25, сайт попадает в зону poor (плохо), что напрямую влияет на ранжирование и поведенческие факторы.

Шрифты являются одной из главных причин резких сдвигов. Проблема заключается в механизме работы браузера. Когда страница начинает загружаться, браузер сначала рендерит текст системным шрифтом (например, Arial), который уже есть в операционной системе пользователя. Как только скачивается ваш красивый кастомный шрифт, браузер заменяет им системный. Но дело в том, что у разных шрифтов разные параметры: у одного буквы чуть шире, у другого - выше межстрочный интервал. В итоге длина строки меняется, абзацы переносятся на следующую строку, и весь контент «прыгает».

Этот процесс называется FOIT (Flash of Invisible Text) или FOUT (Flash of Unstyled Text). Если текст на мгновение становится невидимым, а потом резко появляется, меняя геометрию блоков, вы получаете высокий CLS. Для владельца бизнеса это означает не только плохие показатели в Core Web Vitals, но и раздражение пользователей. Человек может случайно кликнуть не туда, что снижает конверсию в целевое действие.

Важно понимать, что оптимизация CLS - это не просто «сделать шрифт быстрее». Это комплексная работа с геометрией текста. Нужно сделать так, чтобы системный шрифт (fallback) занимал в массе своей то же пространство, что и основной веб-шрифт. Если вы правильно настроите отступы и размеры, пользователь даже не заметит момента переключения шрифтов, так как структура страницы останется неподвижной.

Почему это критично для SEO в 2026 году

Поисковые роботы оценивают стабильность страницы не по субъективным ощущениям, а по реальным данным пользователей (CrUX). Если ваш сайт на мобильных устройствах постоянно «дергается» при загрузке из-за тяжелых шрифтов, это будет зафиксировано как низкое качество интерфейса. В условиях жесткой конкуренции в выдаче преимущество получат те ресурсы, которые обеспечивают мгновенную и стабильную визуальную отрисовку контента.

Выбор стратегии: font-display swap или optional

Когда мы говорим об оптимизации web fonts CLS, первым делом мы выбираем стратегию отображения текста через CSS-свойство font-display. Это фундаментальный выбор, который определяет, как браузер будет вести себя в ожидании загрузки файла шрифта. Здесь нет универсального решения, все зависит от того, что важнее для вашего бренда: мгновенная читаемость или идеальная стабильность верстки.

Стратегия font-display: swap - это классический подход. Браузер сразу показывает текст системным шрифтом, а как только ваш шрифт загружается, он мгновенно подменяет его. Это гарантирует, что пользователь сразу сможет читать контент, не глядя на пустой экран. Однако у swap есть существенный минус: если размеры букв в системном и основном шрифтах сильно различаются, произойдет тот самый визуальный скачок, который увеличивает CLS. Это идеальный вариант для контентных сайтов, блогов и лонгридов, где важно, чтобы текст был доступен немедленно.

Если же ваша приоритетная задача - минимальный CLS, то ваш выбор - font-display: optional. Это более жесткая стратегия. Бразер дает шрифту очень короткое окно загрузки (около 100 мс). Если за это время файл не успел загрузиться, браузер вообще не будет его менять в текущей сессии, и пользователь будет видеть только системный шрифт. Это максимально стабильно: верстка не прыгнет, потому что шрифт просто не будет подгружен "на лету". Но есть нюанс: если пользователь вернется на страницу через секунду, шрифт может уже быть в кэше, и тогда он отобразится. Это лучший выбор для интерфейсов, где важна стабильность (личные кабинеты, панели управления, сложные веб-приложения).

Сравним эти подходы для наглядности:

Свойство Приоритет Риск CLS Применение
font-display: swap Читаемость (скорость) Высокий (из-за смены размеров) Статьи, новости, лендинги
font-display: optional Стабильность (Layout) Минимальный (почти нулевой) Сервисы, приложения, UI-элементы
font-display: fallback Баланс Средний Универсальные проекты

Выбор font-display: fallback является промежуточным вариантом. Он дает короткий период ожидания, а затем переходит в режим swap, если шрифт загружается чуть позже. Это компромиссный вариант, который часто выбирают, когда нужно и текст показать быстро, и не допустить слишком сильных искажений при очень медленном интернете.

Как использовать метрические оверрайды для fallback

Если вы выбрали стратегию swap, вам нужно решить проблему разницы в размерах шрифтов. Это решается через метрические оверрайды (metric overrides). Это относительно новая и очень мощная техника, позволяющая «подгонять» параметры системного шрифта под параметры вашего основного веб-шрифта. Мы не просто говорим браузеру "используй Arial", мы говорим "используй Arial, но сделай его чуть выше и с другим межстрочным интервалом, чтобы он точно встал в те же границы, что и наш основной шрифт".

Для этого используются специальные CSS-свойства:

  1. ascent-override - регулирует высоту верхней части буквы относительно базовой линии.
  2. descent-override - управляет тем, насколько глубоко буквы уходят под базовую линию.
  3. line-gap-override - позволяет изменить межстрочный интервал (line gap) системного шрифта.

Как это работает на практике? Допустим, ваш основной шрифт - элегантный Serif с высокими выносными элементами. Системный шрифт Sans-Serif гораздо компактнее. Если вы просто включите swap, текст "развалится". Но если вы пропишете через метрические оверрайды, что системному шрифту нужно увеличить ascent на 10% и изменить line-gap, то при подмене шрифта блок текста останется того же объема. Это и есть профессиональный подход к оптимизации web fonts CLS.

Чтобы это реализовать, вам нужно сначала замерить параметры вашего основного шрифта (его ascent, descent и line-gap). Это можно сделать с помощью инструментов разработчика в браузере или специальных онлайн-калькуляторов. После получения данных вы прописываете их в @font-face для вашего fallback-шрифта. Это позволяет практически полностью нивелировать визуальный скачок при смене шрифта, сохраняя высокий CLS в зоне "Good".

Важно помнить: использование оверрайдов требует тщательного тестирования. Если вы переборщите с параметрами, системный шрифт может начать выглядеть неестественно (буквы будут слишком сильно наезжать друг на друга или разлетаться). Однако, если настроить их точно, вы получите эффект "невидимой подмены", который критически важен для качественных B2B-ресурсов и сложных интерфейсов.

Преимущества self-hosting и формата WOFF2

Долгое время стандартом было подключение шрифтов через Google Fonts через тег . Однако в 2026 году для серьезных проектов этот метод уже не является приоритетным. Почему? Потомуы что self-hosting (размещение шрифтов на своем сервере) дает гораздо больше контроля над скоростью загрузки и стабильностью. Когда шрифт лежит на вашем домене, браузеру не нужно устанавливать новое соединение с другим сервером (например, с Google), что экономит время на DNS-запросы и TLS-handshake.

Главное преимущество самохостинга - это возможность максимально эффективно использовать формат WOFF2. На текущий момент это самый продвинутый формат сжатия шрифтов. Он обеспечивает невероятно высокую степень компрессии без потери качества, что делает файлы максимально легкими. Чем меньше весит файл, тем быстрее он загружается, и тем меньше вероятность того, что пользователь увидит "прыгающий" контент. Используя только WOFF2, вы сокращаете время загрузки шрифта в разы по сравнению со старыми форматами вроде TTF или OTF.

Кроме того, самохостинг позволяет вам контролировать количество загружаемых начертаний (weights) и подмножеств (subsets). Типичная ошибка - загружать весь семейство шрифтов: Regular, Italic, Bold, Light, ExtraBold и т.д. Это создает огромную нагрузку. Практичный подход 2026 года - загружать только те веса, которые реально используются в дизайне (например, только 400 и 700), и только те символы, которые нужны (кириллица + латиница). Это радикально уменьшает объем передаваемых данных.

Еще один плюс самохостинга - это отсутствие проблем с CORS (Cross-Origin Resource Sharing). Если вы подключаете шрифты с другого домена, вам нужно правильно настроить заголовки на том сервере, иначе браузер может заблокировать их загрузку. Размещая шрифты на своем сервере, вы избавляетесь от этой головной боли и гарантируете, что они загрузятся всегда.

Автоматизация через next/font в современных проектах

Для разработчиков на Next.js процесс оптимизации шрифтов стал максимально простым благодаря модулю next/font. Это стандарт индустрии, который автоматизирует большинство сложных процессов, которые мы обсуждали выше. Если вы используете этот инструмент, вам не нужно вручную настраивать self-hosting или бороться с параметрами подключения - система сделает это за вас.

Как работает настройка next/font для SEO и производительности? Когда вы используете пакет `next/font/google`, Next.js при сборке проекта сам скачивает шрифты из Google Fonts и делает их self-hosting'ом. Это означает, что в продакшене ваш сайт не будет делать запросов к серверам Google, а будет брать шрифты напрямую с вашего домена. Это решает проблему лишних соединений и ускоряет загрузку.

Более того, `next/font` по умолчанию включает механизм автоматического fallback-шрифта для снижения CLS. Он автоматически вычисляет необходимые метрики и подбирает системный шрифт, который максимально похож на ваш кастомный. Это избавляет разработчика от необходимости вручную высчитывать ascent-override и descent-override. Для локальных шрифтов (`next/font/local`) вы можете вручную указать, какой системный шрифт использовать в качестве запасного (например, Arial или Times New Roman), что дает полный контроль над ситуацией.

Использование `next/font` - это золотой стандарт для современных SPA и SSR приложений. Он автоматически оптимизирует загрузку, предотвращает невидимый текст (FOIT) и минимизирует сдвиги макета. Если ваш проект построен на Next.js, использование этого модуля - это не просто рекомендация, а обязательное условие для поддержания высоких показателей Core Web Vitals и успешного SEO.

Preload критических шрифтов для быстрой загрузки

Если шрифт является основным для заголовков или основного текста (body), он должен быть загружен в первую очередь. Для этого используется механизм preload (предварительная загрузка). Когда вы добавляете ``, вы даете браузеру команду: "Этот файл критически важен, начни скачивать его прямо сейчас, не дожидаясь, пока парсер дойдет до CSS-правил".

Однако с preload нужно быть осторожным. Это "оружие двойного назначения". Если вы добавите в preload слишком много файлов (например, все начертания шрифта), вы создадите очередь на загрузку, которая может замедлить загрузку самого CSS или критических JS-скриптов. Это приведет к тому, что страница будет долго оставаться "белой" или неполной. Правило простое: preload только те шрифты, которые пользователь видит в первом экране (above the fold).

Оптимальная стратегия выглядит так:

  1. Определите 1-2 самых важных шрифта (например, основной заголовок и основной текст).
  2. Убедитесь, что они загружаются в формате WOFF2.
  3. Используйте `preload` только для этих файлов.
  4. Остальные (вспомогательные, иконочные шрифты) оставляйте на стандартной загрузке.

Еще один нюанс - атрибут `crossorigin`. При использовании preload для шрифтов этот атрибут обязателен, даже если шрифт загружается с вашего собственного домена. Без него браузер может загрузить шрифт дважды: один раз через preload, а второй раз - когда встретит его в CSS. Это лишний трафик и лишний риск сдвига контента при повторной загрузке.

Типичные ошибки при подключении Google Fonts

Несмотря на удобство Google Fonts, многие разработчики допускают ошибки, которые убивают производительность и задирают CLS. Самая распространенная ошибка - подключение шрифтов через стандартный тег без параметров оптимизации. Если вы просто копируете код из Google Fonts, вы можете забыть про параметр `&display=swap`. Без него браузер может на какое-то время вообще не показывать текст, пока шрифт не загрузится, что создает эффект "мигающего" контента.

Вторая ошибка - избыточность. Мы часто видим сайты, где подключено 5-6 разных семейств шрифтов и по 4-5 начертаний у каждого. Это катастрофа для скорости загрузки. Каждый новый шрифт - это дополнительные запросы и дополнительные байты. На практике это выглядит так: вместо одного файла на 30 КБ вы загружаете 150 КБ, и браузер тратит время на обработку этой кучи данных вместо того, чтобы отрисовать страницу.

Третья ошибка - использование шрифтов в формате TTF или OTF вместо WOFF2. Старые форматы значительно тяжелее. Если вы используете их, вы добровольно заставляете пользователя ждать дольше и увеличиваете риск CLS. Всегда конвертируйте свои шрифты в WOFF2 перед загрузкой на сервер.

И, наконец, ошибка - игнорирование мобильных пользователей. На медленных сетях 3G/4G проблема CLS от шрифтов проявляется в разы сильнее, чем на десктопах с быстрым Wi-Fi. Если ваш сайт "прыгает" на мощном компьютере, то на смартфоне в метро пользователь просто не сможет нормально пользоваться вашим ресурсом. Всегда тестируйте скорость загрузки и стабильность верстки в режиме эмуляции медленной сети в Chrome DevTools.

Чек-лист для проверки CLS перед запуском сайта

Перед тем как выпустить проект в продакшн, пройдитесь по этому списку. Если хотя бы один пункт не выполнен, ваш сайт может получить низкие оценки в Core Web Vitals.

  • Формат: Все шрифты используются в формате WOFF2.
  • Стратегия: Для основного текста выбран font-display: swap или optional.
  • Self-hosting: Шрифты загружаются с вашего домена, а не через внешние ссылки (Google Fonts).
  • Метрики: Для шрифтов, вызывающих сдвиги, настроены метрические оверрайды (ascent/descent override).
  • Минимализм: Загружается только необходимый набор весов и подмножеств (кириллица/латиница).
  • Preload: Только критически важные шрифты (первый экран) добавлены через preload.
  • Тестирование: Проверка CLS проведена в режиме эмуляции медленной сети (Throttling) в Chrome DevTools.

Что запомнить:

  • Целевой CLS - ниже 0.1.
  • Используйте WOFF2 и self-hosting для максимального контроля.
  • Для стабильности UI выбирайте font-display: optional.
  • Метрические оверрайды - лучший способ победить FOUT без потери дизайна.

← Все статьи
Поделиться:

Хотите так же?

Начнём с бесплатной диагностики: покажем, где теряются деньги и как система продаж, AI и автоматизация ускорят рост.