Оптимизация шрифтов: font-display, preload и конец невидимого текста

Веб-шрифты делают сайт красивым, но именно они чаще всего виноваты в том, что посетитель несколько секунд смотрит на пустой экран или наблюдает, как текст внезапно меняет начертание и «прыгает» по странице. На большинстве проектов, которые приходят к нам на технический аудит, шрифты грузятся неоптимально: подключены через сторонний домен, весят сотни килобайт, блокируют отрисовку и роняют показатели Core Web Vitals. В этой статье разберём по полочкам, как работают веб-шрифты, что такое FOIT и FOUT, как настроить свойство font-display, выполнить preload и сабсеттинг, и почему иногда самый правильный шрифт — это вообще никакого кастомного шрифта.

Почему веб-шрифты тормозят рендеринг страницы

Когда браузер встречает в CSS правило @font-face, он не загружает шрифт сразу. Файл скачивается только тогда, когда браузер понимает, что на странице действительно есть текст, использующий это семейство. Это значит, что цепочка событий выглядит так: загрузка HTML, разбор CSS, построение дерева отрисовки, обнаружение нужного шрифта, запрос файла по сети, ожидание ответа, декодирование и только потом — отрисовка текста этим шрифтом. Каждое звено добавляет задержку, а пользователь в это время видит либо пустоту, либо текст системным шрифтом.

Проблема усугубляется тем, что один веб-шрифт редко бывает один. На типичном корпоративном сайте подключают обычное начертание, полужирное, иногда курсив и заголовочный вариант — четыре файла вместо одного. Если каждый весит 80–150 КБ и грузится со стороннего домена, который требует отдельного DNS-запроса, установки TCP-соединения и TLS-рукопожатия, суммарная задержка легко превышает секунду даже на хорошем канале. На мобильном интернете в регионах эта цифра удваивается.

Шрифты — это критический ресурс для восприятия контента, но при этом они конкурируют за пропускную способность с изображениями, скриптами и стилями. Если не управлять приоритетами явно, браузер может отложить загрузку шрифта в пользу менее важного ресурса. Именно поэтому грамотная работа со шрифтами — это не косметика, а часть технической оптимизации, тесно связанная с критическим CSS и устранением render-blocking ресурсов.

FOIT и FOUT: невидимый текст и мелькание шрифта

Пока веб-шрифт грузится, браузеру нужно решить, что показывать пользователю. Исторически сложилось два сценария поведения, и оба имеют свои недостатки.

FOIT — Flash of Invisible Text

FOIT, или вспышка невидимого текста, — это ситуация, когда браузер прячет текст до тех пор, пока веб-шрифт не загрузится полностью. Пользователь видит пустые места там, где должны быть заголовки и абзацы. По умолчанию большинство браузеров держат текст невидимым около трёх секунд, и только потом, если шрифт так и не пришёл, показывают резервный. Для пользователя на медленном соединении это означает, что главный контент страницы фактически недоступен в первые секунды, хотя HTML уже загружен. Это прямой удар по показателю Largest Contentful Paint, особенно если LCP-элемент — крупный текстовый блок.

FOUT — Flash of Unstyled Text

FOUT, или вспышка нестилизованного текста, — противоположный подход. Браузер сразу показывает текст резервным системным шрифтом, а когда веб-шрифт догружается, перерисовывает его уже нужным начертанием. Пользователь видит контент мгновенно, но затем замечает, как буквы меняют форму, насыщенность и ширину. Если резервный и целевой шрифт сильно отличаются по метрикам, при подмене происходит сдвиг строк и абзацев — это бьёт по Cumulative Layout Shift. Подробно механику скачков мы разбираем в материале про CLS и борьбу с прыжками вёрстки.

Идеального варианта по умолчанию не существует: FOIT прячет контент, FOUT его дёргает. Задача оптимизатора — не выбрать меньшее зло вслепую, а управлять поведением через font-display, preload и подбор метрик резервного шрифта.

Свойство font-display: swap, optional, fallback, block

Дескриптор font-display задаётся внутри правила @font-face и говорит браузеру, как себя вести в период загрузки шрифта. У него четыре основных значения, и понимание разницы между ними напрямую влияет на ваши метрики.

Значение	Период блокировки	Поведение	Когда применять
block	~3 с	Текст невидим, затем резервный, потом подмена	Иконочные шрифты, логотипы
swap	0 с	Сразу резервный, затем подмена на веб-шрифт	Основной текст, заголовки
fallback	~100 мс	Короткая невидимость, затем резервный; подмена только если успел	Баланс скорости и стиля
optional	~100 мс	Как fallback, но подмены может не быть совсем	Максимальная скорость, борьба с CLS

Значение swap гарантирует, что текст виден сразу, и устраняет FOIT, но допускает FOUT и связанный с ним сдвиг вёрстки. Это самый популярный выбор для контентных сайтов, где важно, чтобы пользователь начал читать немедленно. Значение optional — наиболее агрессивное в плане производительности: браузер даёт шрифту крошечное окно на загрузку, и если тот не успел, использует резервный до конца сессии, не делая подмену. Это полностью исключает поздний сдвиг от шрифта, что критично для прохождения порогов CLS.

На практике мы рекомендуем такую стратегию: для основного текста — swap в связке с preload и подобранными метриками резервного шрифта, для второстепенных декоративных начертаний — optional, для иконочных шрифтов, где резервный символ выглядит как «кракозябра», — block. Универсального ответа нет, выбор зависит от того, что важнее на конкретной странице: мгновенная читаемость или стабильность макета.

Preload ключевых шрифтов

Главная проблема веб-шрифтов в том, что браузер обнаруживает их поздно — только после загрузки и разбора CSS. Решение — заранее сказать браузеру, что этот файл понадобится, с помощью предзагрузки. В секцию <head> добавляется тег вида: <link rel=»preload» as=»font» type=»font/woff2″ href=»/fonts/main.woff2″ crossorigin>.

Здесь важны три детали. Во-первых, атрибут as=»font» задаёт правильный приоритет и тип ресурса. Во-вторых, атрибут crossorigin обязателен даже для шрифтов с того же домена — без него браузер сделает повторный запрос, и предзагрузка окажется бесполезной. Это самая частая ошибка, которую мы видим в аудитах. В-третьих, предзагружать стоит только те шрифты, которые реально нужны для первого экрана — обычно это одно-два начертания. Если предзагрузить всё, вы перегрузите сеть и замедлите более важные ресурсы.

• Предзагружайте только шрифты, видимые на первом экране без прокрутки.
• Всегда добавляйте crossorigin, иначе запрос продублируется.
• Указывайте формат woff2 — он поддерживается всеми актуальными браузерами.
• Не предзагружайте курсив и редкие начертания — для них достаточно swap или optional.

Проверить, что предзагрузка действительно ускоряет рендеринг, удобно во вкладке Network в Chrome DevTools и через водопадную диаграмму в WebPageTest. Вы увидите, что запрос на шрифт стартует раньше, не дожидаясь окончания разбора CSS. В Lighthouse и PageSpeed Insights корректная предзагрузка убирает предупреждение об отложенной загрузке шрифтов.

Сабсеттинг: вырезаем лишние глифы

Полноценный шрифтовой файл содержит тысячи глифов: латиницу, кириллицу, греческий, расширенную пунктуацию, математические символы, лигатуры. Если ваш сайт на русском языке, вам не нужны греческие и вьетнамские символы — они только утяжеляют файл. Сабсеттинг (subsetting) — это вырезание из шрифта неиспользуемых символов, чтобы оставить только нужный поднабор.

Для русскоязычного сайта обычно достаточно кириллицы, базовой латиницы и знаков пунктуации. Сабсеттинг способен уменьшить вес файла в два-три раза: шрифт на 120 КБ после вырезания лишних диапазонов может занять 40–50 КБ. Сделать это можно инструментами вроде glyphhanger, fonttools (pyftsubset) или онлайн-конвертерами. Если используете Google Fonts через self-hosting, при выгрузке шрифта обращайте внимание на параметр диапазона символов в URL — там часто можно сразу запросить только кириллический сабсет.

Формат файла тоже имеет значение. Современный стандарт — woff2: он использует сжатие Brotli и весит на 25–30% меньше, чем устаревший woff. Старые форматы ttf и eot подключать в 2025 году уже не нужно — их поддержка в актуальных браузерах не требуется. Один файл woff2 на начертание — это всё, что нужно. Тема сжатия шире, чем шрифты, и мы её детально раскрываем отдельно, но логика та же, что в материале про улучшение скорости загрузки и Core Web Vitals.

Self-hosting против Google Fonts

Долгие годы стандартом было подключение шрифтов через CDN Google Fonts двумя строчками. Это удобно, но у такого подхода есть существенные минусы, которые в 2025 году перевешивают удобство.

Во-первых, скорость. Подключение со стороннего домена требует отдельного DNS-запроса, нового TCP-соединения и TLS-рукопожатия к fonts.googleapis.com и fonts.gstatic.com. Это добавляет сотни миллисекунд ещё до того, как начнётся загрузка самого файла. Когда шрифт лежит на вашем домене рядом с остальными ресурсами, он переиспользует уже установленное соединение и грузится быстрее. Во-вторых, приватность и юридические риски: в ряде стран использование Google Fonts через CDN признали нарушением законодательства о персональных данных, поскольку IP-адрес пользователя передаётся на серверы Google. Self-hosting снимает этот вопрос полностью.

В-третьих, контроль. Размещая шрифт у себя, вы сами решаете, какой сабсет использовать, какой font-display задать и какие начертания предзагрузить. Вы не зависите от доступности стороннего домена, который в российских реалиях может работать нестабильно. Поэтому для проектов, ориентированных на аудиторию в России, мы практически всегда переводим шрифты на self-hosting в рамках технической доработки сайта.

Критерий	Google Fonts CDN	Self-hosting
Скорость первого запроса	Медленнее (новый домен)	Быстрее (общее соединение)
Приватность	IP уходит на Google	Полный контроль
Доступность в РФ	Возможны сбои	Стабильно
Контроль над сабсетом	Ограниченный	Полный
Простота подключения	Очень просто	Требует настройки

Системные шрифты — самый быстрый вариант

Самый быстрый веб-шрифт — это тот, который не нужно загружать вообще. Системный шрифтовой стек использует шрифты, уже установленные в операционной системе пользователя: San Francisco на устройствах Apple, Segoe UI в Windows, Roboto в Android. Браузеру не нужно ничего скачивать, текст отрисовывается мгновенно, FOIT и FOUT исчезают как класс, а CLS от подмены шрифта становится невозможным.

Типичное правило выглядит так: font-family: -apple-system, BlinkMacSystemFont, «Segoe UI», Roboto, «Helvetica Neue», Arial, sans-serif. Текст всегда будет показан красивым нативным шрифтом конкретной платформы. Минус очевиден: вы теряете уникальность бренда, потому что на разных устройствах сайт выглядит немного по-разному. Но для многих проектов, особенно для блогов и информационных разделов, выигрыш в скорости важнее, чем фирменная гарнитура. Хороший компромисс — системный стек для основного текста и один кастомный шрифт только для заголовков и логотипа.

size-adjust и ascent-override против CLS

Главная причина сдвига вёрстки при подмене шрифта в том, что резервный и целевой шрифты имеют разные метрики: высоту строчных букв, высоту прописных, ширину символов. Когда системный Arial меняется на ваш фирменный шрифт, блок текста может стать выше или ниже, и весь контент под ним сдвинется. Раньше с этим почти ничего нельзя было сделать, кроме как использовать optional.

Современные дескрипторы @font-face решают проблему элегантно. Свойства size-adjust, ascent-override, descent-override и line-gap-override позволяют масштабировать и подгонять метрики резервного шрифта так, чтобы он занимал ровно то же пространство, что и веб-шрифт. В результате подмена происходит без единого пикселя сдвига — пользователь видит только смену начертания, но макет остаётся неподвижным. Это лучший на сегодня способ совместить swap (мгновенная видимость) и нулевой CLS.

• Создайте дополнительное @font-face для резервного шрифта с подобранными метриками.
• Используйте size-adjust для масштабирования ширины символов.
• Применяйте ascent-override и descent-override для выравнивания высоты строки.
• Проверяйте результат в DevTools на слое сдвигов макета.

Влияние шрифтов на Core Web Vitals

Шрифты влияют сразу на два из трёх ключевых показателей Core Web Vitals. На LCP — потому что если самый крупный элемент на экране это текстовый блок, его отрисовка откладывается до загрузки шрифта при стратегии block или при медленном swap без preload. Ускорить отрисовку главного контента помогает связка preload плюс swap, о чём мы подробно пишем в гайде про ускорение LCP и загрузку главного контента.

На CLS — потому что поздняя подмена шрифта с другими метриками сдвигает текст. Здесь спасают либо optional, либо переопределение метрик через size-adjust. Третий показатель, INP, шрифты затрагивают косвенно: лишние сетевые запросы и тяжёлые файлы нагружают главный поток в момент загрузки. Измерять реальное влияние нужно по полевым данным — отчёт CrUX и группировка URL в Search Console показывают, как шрифты ведут себя у настоящих пользователей, а не только в лабораторном Lighthouse.

На практике грамотная оптимизация шрифтов на типичном WordPress-сайте даёт улучшение LCP на 0,3–0,8 секунды и снижение CLS до нуля по шрифтовой составляющей. Эти доли секунды напрямую отражаются на месте в выдаче, потому что Core Web Vitals — подтверждённый фактор ранжирования. Если хотите проверить, как обстоят дела с вашими шрифтами, начните с комплексного SEO аудита.

Чек-лист оптимизации шрифтов

1. Переведите шрифты с Google Fonts CDN на self-hosting со своего домена.
2. Используйте только формат woff2, откажитесь от ttf, eot и woff.
3. Выполните сабсеттинг: оставьте кириллицу, латиницу и пунктуацию.
4. Сократите число начертаний до реально используемых — обычно двух-трёх.
5. Задайте font-display: swap для основного текста, optional для декоративных.
6. Предзагрузите шрифты первого экрана через rel=»preload» с crossorigin.
7. Подберите метрики резервного шрифта через size-adjust и ascent-override.
8. Рассмотрите системный шрифтовой стек для основного текста.
9. Проверьте результат в Lighthouse, WebPageTest и по полевым данным CrUX.

Оптимизация шрифтов — это недорогая, но очень эффективная часть технического SEO: она почти не требует переделки дизайна, но заметно улучшает скорость и стабильность страницы. Если вы хотите, чтобы вашими шрифтами и всей технической базой занимались эксперты, закажите SEO-продвижение сайта в нашем агентстве или начните с SEO-консультации, где мы разберём ваш проект и составим план технической оптимизации.

Услуги LSI Продвижение

Наша команда предлагает полный спектр услуг по SEO-продвижению и технической доработке сайтов. Мы работаем только белыми методами, ориентируемся на реальный бизнес-результат — трафик, заявки и продажи, а не только позиции в отчёте, — и выстраиваем продвижение системно, под конкретные задачи и нишу вашего проекта. Начать можно с бесплатной диагностики, чтобы понять текущее состояние сайта и точки роста, а затем перейти к комплексной работе. Выберите подходящую услугу из списка ниже:

• Бесплатный SEO аудит сайта — автоматическая проверка на 50+ параметров за 2 минуты
• Комплексный SEO аудит — глубокий ручной анализ с рекомендациями от эксперта
• Продвижение сайтов — вывод в ТОП Яндекса и Google по целевым запросам
• SEO консультация — разбор вашего сайта с конкретными рекомендациями
• LSI тексты — экспертный контент, оптимизированный для поисковых систем
• Доработка сайта — техническая оптимизация и исправление ошибок
• Создание сайта под ключ — разработка с нуля с SEO-оптимизацией
• Стоимость продвижения — прозрачные тарифы и условия
• Портфолио и кейсы — реальные результаты наших клиентов