Шрифты и скорость сайта: скрытый тормоз

Когда сайт медленный, первым делом сжимают картинки, выносят скрипты и подключают кэш. Шрифты при этом остаются нетронутыми — они весят «всего» пару сотен килобайт и кажутся мелочью. Между тем именно веб-шрифты чаще всего дают самую заметную часть Cumulative Layout Shift, откладывают отрисовку основного текста и удлиняют Largest Contentful Paint на сотни миллисекунд, потому что подключаются в самом неудачном месте цепочки загрузки — после того, как браузер уже разобрал CSS и построил дерево. Причём на русскоязычных сайтах проблема острее: кириллический набор глифов тяжелее латинского, а типовые способы подключения через сторонние CDN добавляют лишние соединения и риск недоступности. Разбираем механику от первого байта до стабильной вёрстки и показываем, что именно чинить в рамках SEO-продвижения сайта.

Почему шрифты попадают в слепую зону оптимизации

Проверка скорости обычно выглядит так: прогнали страницу через PageSpeed Insights, посмотрели список рекомендаций, отдали разработчику. В списке шрифты либо не всплывают вовсе, либо появляются одной строкой «Ensure text remains visible during webfont load». Строка выглядит косметической, её откладывают. Результат: сайт с идеально пережатыми изображениями и отложенным JavaScript всё равно показывает пустые блоки текста в первые секунды и получает сдвиг макета при подмене шрифта.

Причина недооценки — в неправильной ментальной модели. Шрифт воспринимается как «ещё одна картинка», то есть как ресурс, который просто занимает килобайты. На деле у него три особенности, которых нет ни у изображений, ни у скриптов.

Первая — позднее обнаружение. Браузер находит шрифт не в HTML, а внутри CSS: сначала нужно загрузить и распарсить таблицу стилей, построить CSSOM, сопоставить селекторы с реальными узлами и только потом понять, что для этого текста требуется файл шрифта. Между началом загрузки страницы и стартом запроса за шрифтом проходит время, которого нет у ресурсов, объявленных прямо в разметке.

Вторая — блокировка отрисовки текста. Пока файл не пришёл, браузер по умолчанию не рисует текст вообще. Не рисует запасным шрифтом, а именно прячет: это поведение называется FOIT, Flash of Invisible Text. Пользователь видит картинки, фон, кнопки без подписей — и пустоту там, где должен быть заголовок.

Третья — геометрия. Когда шрифт наконец приходит, текст перерисовывается уже другой гарнитурой, с другой шириной символов и другой высотой строки. Абзац, занимавший четыре строки, становится пятистрочным. Всё, что ниже, съезжает вниз. Это и есть layout shift — и он считается системой Core Web Vitals наравне с любым другим сдвигом.

Изображение без размеров сдвигает макет один раз и заметно. Шрифт сдвигает его тихо, на каждом текстовом блоке страницы сразу — и потому суммарно часто даёт больший вклад в CLS.

Как браузер на самом деле загружает шрифт

Чтобы понимать, где именно вставлять правки, нужно держать в голове полную цепочку. Она одинакова во всех современных браузерах, различия только в длительности таймаутов.

Из этой цепочки следуют все практические выводы. Ускорить пункт 1 — значит убрать сторонние домены и уменьшить критический CSS. Ускорить пункт 4 — значит объявить шрифт заранее через preload, чтобы запрос ушёл параллельно с CSS, а не после него. Обезвредить пункт 6 — значит подогнать метрики фолбэка так, чтобы подмена прошла без изменения геометрии. Ниже — по каждому пункту отдельно. Общий контекст по метрикам скорости мы разбирали в материале про Core Web Vitals: LCP, CLS и INP, здесь же речь идёт исключительно о шрифтовой части.

font-display: одно свойство, пять сценариев

Дескриптор font-display внутри @font-face управляет тем, что происходит с текстом, пока шрифт едет. Это первое, что нужно проверить в любом аудите: его отсутствие — самая частая шрифтовая ошибка вообще.

Практическая логика выбора выглядит так. swap устраняет FOIT и спасает LCP, но не устраняет CLS — сдвиг просто переносится с «текста нет» на «текст перерисовался». optional — единственное значение, которое гарантированно убирает шрифтовой CLS: браузер либо успевает взять файл из кэша за отведённые ~100 мс, либо навсегда остаётся на фолбэке для этой загрузки страницы, а скачанный файл кладёт в кэш для следующих визитов. Цена — первый визит пользователь видит системный шрифт.

CLS: как подмена шрифта ломает вёрстку и как это чинить

Сдвиг при свапе возникает потому, что запасной шрифт и целевой имеют разные метрики. Ключевых параметров три: средняя ширина глифа (влияет на количество строк в абзаце), высота строчных букв x-height (влияет на визуальную плотность) и вертикальные метрики ascent/descent (влияют на высоту строки). Arial и, скажем, узкая гротескная гарнитура при одинаковом font-size дают разное число строк на один и тот же текст — и разницу видно как рывок макета.

Подгонка метрик через дескрипторы @font-face

Современный CSS позволяет объявить «локальный фолбэк с исправленными метриками» и использовать его в стеке шрифтов. Механика такая: создаётся отдельный @font-face, в котором src ссылается на системный шрифт через local(), а четыре дескриптора корректируют его геометрию под целевую гарнитуру.

• size-adjust — масштабирует глифы в процентах. Основной рычаг: подбирается так, чтобы средняя ширина строки фолбэка совпала с целевой.
• ascent-override — задаёт высоту над базовой линией. Отвечает за верхнюю границу строки.
• descent-override — задаёт глубину подстрочных элементов.
• line-gap-override — межстрочный зазор, обычно выставляется в 0%.

Значения не угадываются, а вычисляются из таблиц метрик обоих шрифтов. Есть готовые генераторы, но принцип полезно понимать: соотношение unitsPerEm и hhea-метрик целевого шрифта переносится на фолбэк. После правильной подгонки переключение с системного шрифта на брендовый визуально почти незаметно, а CLS от него становится нулевым при сохранении font-display: swap. Это самый сильный приём в теме и одновременно самый редко применяемый на практике.

Что ещё даёт сдвиг помимо самого свапа

• Динамический подбор размера JS-скриптом — библиотеки «умного» уменьшения заголовков под ширину контейнера срабатывают после загрузки шрифта и добавляют ещё один сдвиг поверх первого.
• Кнопки и бейджи с текстом внутри — их ширина зависит от ширины строки, а значит, при свапе меняется вся сетка вокруг.
• Иконочные шрифты в шапке — иконка до загрузки занимает место одного символа-заглушки, после загрузки становится квадратной, элементы навигации разъезжаются.
• Отсутствие min-height у первого экрана — если высота hero-блока определяется длиной заголовка, свап двигает вообще всё содержимое страницы.

Порог, к которому надо идти: CLS не выше 0,1 у 75-го перцентиля реальных пользователей. Значение 0,1–0,25 считается «требует улучшения», выше 0,25 — «плохо». Шрифтовой вклад считается просто: снимите два прогона в лаборатории — с включённым веб-шрифтом и с принудительным фолбэком — и сравните дельту. Обычно она объясняет от четверти до половины всего CLS на контентных страницах.

Кириллица: почему у русских сайтов файлы тяжелее

Латинский базовый набор — это примерно сотня глифов. Кириллический добавляет ещё около семидесяти, и это только базовый диапазон U+0400–U+04FF. Проблема в другом: большинство популярных гарнитур поставляются одним файлом, в который упакованы латиница, кириллица, греческий, вьетнамский, расширенная латиница, символы валют, математические знаки, стрелки и лигатуры. Русскоязычный сайт использует из этого богатства процентов двадцать, а платит за все сто.

Что такое сабсеттинг и как его делать

Сабсеттинг — это пересборка файла шрифта с сохранением только нужных диапазонов Unicode. Стандартный инструмент — pyftsubset из библиотеки fontTools; есть надстройки вроде glyphhanger, которые сами сканируют сайт и составляют список реально используемых символов.

Минимальный практический набор для русского коммерческого сайта:

Второй приём — не один сабсет, а несколько @font-face с разными unicode-range: отдельно кириллица, отдельно латиница, отдельно пунктуация. Браузер сам скачает только те файлы, символы из которых реально встретились на странице. Для многоязычных проектов это обязательная схема; принципы работы с несколькими языковыми версиями мы разбирали в статье про hreflang и мультиязычные сайты.

Форматы файлов: почему всё, кроме WOFF2, — лишнее

Классический «пуленепробиваемый @font-face» из руководств десятилетней давности перечисляет пять форматов: EOT для старого IE, TTF/OTF, WOFF, WOFF2 и SVG для древних мобильных Safari. Такая конструкция до сих пор кочует по шаблонам и генераторам.

Практическое следствие: почистите @font-face до одной строки src с WOFF2. Это не только уменьшает вес — это убирает риск, что браузер скачает не тот формат из-за неправильного порядка перечисления. И проверьте, что сервер отдаёт шрифты с корректным Content-Type и, главное, со сжатием на уровне транспорта отключённым: WOFF2 уже сжат Brotli внутри, повторное gzip-сжатие на nginx только тратит процессорное время. Настройки уровня сервера подробнее — в материале про то, как хостинг влияет на скорость и позиции.

Локально или через CDN: развенчание старого мифа

Аргумент «подключим Google Fonts, он у пользователя уже в кэше с другого сайта» был верен примерно до 2020 года. Затем браузеры перешли на партиционированный кэш: ресурс, скачанный на сайте A, больше не переиспользуется на сайте B, даже если URL идентичен. Это сделано ради приватности — общий кэш позволял отслеживать пользователей. С тех пор общий аргумент в пользу стороннего шрифтового CDN не работает вообще.

Что осталось на чаше «внешний CDN»: не нужно ничего хостить, автоматически отдаётся оптимальный сабсет под браузер. Что на чаше «локально»: полное отсутствие лишних соединений и полный контроль.

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

preload и preconnect: чиним позднее обнаружение

Даже локальный, идеально сабсеченный WOFF2 стартует поздно — после CSS. Лечится это директивой предзагрузки в <head>: <link rel="preload" as="font" type="font/woff2" href="/fonts/main-cyrillic.woff2" crossorigin>. Она заставляет браузер начать загрузку сразу, параллельно с таблицей стилей.

Четыре правила, которые нарушают чаще всего

1. Атрибут crossorigin обязателен всегда. Шрифты запрашиваются в режиме CORS даже с собственного домена. Без crossorigin браузер скачает файл дважды: один раз по preload, второй раз по реальному запросу из CSS. Это самая частая ошибка внедрения — и она делает preload вредным вместо полезного.
2. Предзагружать только то, что видно на первом экране. Preload повышает приоритет ресурса, отбирая пропускную способность у других. Три-четыре предзагруженных шрифта конкурируют между собой и с LCP-изображением, и в сумме страница становится медленнее.
3. Preload не отменяет font-display. Это разные механизмы: preload ускоряет загрузку, font-display определяет поведение во время неё. Нужны оба.
4. Не предзагружать несуществующие пути. Опечатка в href даёт лишний запрос с ответом 404 и предупреждение в консоли, но не даёт ошибки на экране — поэтому живёт годами.

Если по каким-то причинам отказаться от стороннего сервиса нельзя, минимальная компенсация — <link rel="preconnect"> к обоим доменам сервиса (для CSS и для файлов), с тем же crossorigin для файлового домена. Это не убирает лишние соединения, но устанавливает их заранее, пока браузер занят HTML. Полумера, но она стоит одной строки.

Сколько начертаний вам действительно нужно

Типичная ситуация на коммерческом сайте: в @font-face объявлено шесть-восемь начертаний одной гарнитуры — Light, Regular, Medium, SemiBold, Bold, Black плюс курсивы. Реально в вёрстке используются два-три. Каждое лишнее начертание — отдельный файл, отдельный запрос и отдельный вес.

Считайте по факту: пройдите по вёрстке и выпишите, какие значения font-weight встречаются в CSS. Обычно набор сводится к обычному тексту (400), акцентам (600 или 700) и заголовкам. Всё остальное — наследство дизайн-макета, где дизайнер экспериментировал.

Вариативные шрифты: когда это выигрыш, а когда нет

Variable font — один файл, содержащий непрерывную ось начертаний: любое значение веса от 100 до 900 без отдельных файлов. Логика выбора простая арифметика:

• Нужно 1–2 начертания — статические сабсеты почти всегда легче. Вариативный файл несёт в себе всю ось и служебные таблицы, за которые вы платите независимо от того, сколько весов используете.
• Нужно 3–4 начертания — точка безубыточности, считайте на конкретных файлах после сабсеттинга.
• Нужно 5 и больше, есть анимация веса или плавная адаптация под ширину — вариативный вариант выигрывает уверенно.

Отдельно предупреждение: не полагайтесь на синтетическое начертание. Если объявлен только Regular, а в вёрстке стоит font-weight: 700, браузер нарисует «искусственный жирный» — механически утолщит контуры. Выглядит это грязно, а главное — метрики такого текста отличаются и от Regular, и от настоящего Bold, что добавляет ещё один источник сдвигов.

Иконочные шрифты: отдельная категория проблем

Шрифты с иконками (наследие библиотек вроде Font Awesome и самосборных наборов через генераторы) объединяют в себе все шрифтовые проблемы и добавляют свои.

• Вес не соответствует пользе. В наборе сотни глифов, на сайте используются 8–15. Сабсеттинг иконочного шрифта делают редко, потому что он неудобен: коды символов теряются вместе с классами.
• FOIT на иконках выглядит как поломка. До загрузки шрифта на месте иконок либо пусто, либо квадраты-заглушки, либо случайные символы из фолбэка — часто именно этот эффект видят пользователи в первую секунду.
• Гарантированный сдвиг. Иконка меняет ширину при подмене, и вся горизонтальная навигация или строка кнопок перестраивается.
• Доступность и семантика. Скринридер читает служебный символ; поисковый робот при рендеринге видит мусорный глиф в тексте ссылки, если иконка вставлена не через псевдоэлемент.

Правильное решение почти всегда — перевести иконки на SVG: инлайновый спрайт в разметке или отдельный файл со ссылками через <use>. SVG не блокирует отрисовку, не создаёт сдвига (у него есть явные размеры), масштабируется без потерь и корректно читается вспомогательными технологиями. Работа с векторной графикой и её оптимизацией пересекается с общей темой оптимизации изображений на сайте.

Влияние на Core Web Vitals: что именно меняется

Разложим по метрикам, чтобы понимать, чего ждать от каждой правки и как аргументировать её разработчику.

Важное уточнение про измерение. Лабораторные прогоны (Lighthouse, PageSpeed Insights в режиме анализа) почти всегда показывают шрифтовые проблемы мягче, чем они есть: тест идёт с холодным кэшем на смоделированной сети, но без реального разброса условий. Полевые данные — CrUX и Яндекс Метрика с её отчётами по скорости — дают честную картину. Особенно это касается CLS: у 75-го перцентиля реальных пользователей он часто в разы хуже лабораторного, потому что на медленных соединениях свап происходит позже, когда пользователь уже начал читать. Полная методика замеров и приоритизации описана в материале про скорость загрузки сайта.

Пошаговый аудит шрифтов на живом сайте

Последовательность, которую мы проходим на технической части SEO-аудита. Занимает от часа на простом сайте до дня на крупном проекте с несколькими шаблонами.

Восьмой шаг важен не меньше остальных: полевые данные обновляются с задержкой в 28 дней скользящего окна, поэтому сразу после выкатки вы увидите только лабораторные цифры. Планируйте контрольный замер заранее, чтобы результат не потерялся. Как выстроить систему регулярных проверок — в статье про внутреннюю оптимизацию сайта. Примеры технических перестроек на клиентских проектах есть в нашем портфолио.

Особенности популярных CMS и фреймворков

Практика показывает: источник шрифтовых проблем чаще всего не в основном шаблоне, а в том, что подтягивается вокруг него.

• WordPress. Классический сценарий: тема подключает свой набор шрифтов, конструктор страниц — свой, плагин формы — иконочный шрифт, плагин слайдера — ещё один. В сумме на странице оказывается десяток файлов из трёх источников. Начинайте аудит с отключения источников по одному; типовые узкие места разобраны в материале про SEO на WordPress.
• 1С-Битрикс. Шрифты обычно лежат в шаблоне и попадают в объединённый CSS. Ловушка — механизм оптимизации CSS, который может нарушить порядок правил @font-face или переписать относительные пути в src. Детали настройки — в статье про SEO на 1С-Битрикс.
• Конструкторы сайтов. Контроль над @font-face чаще всего отсутствует полностью: шрифты подключаются платформой так, как решила платформа. Максимум доступного — не добавлять сверху собственные внешние шрифты. Границы возможного описаны в разборе SEO на Tilda.
• SPA и приложения на JS-фреймворках. Шрифты нередко импортируются внутри JS-бандла, то есть обнаруживаются ещё позже обычного — после загрузки и выполнения скрипта. Плюс риск, что при серверном рендеринге стили шрифтов приезжают отдельным чанком. Тема пересекается с JavaScript-SEO.

Что шрифты дают бизнесу, а не только метрикам

Скорость — не самоцель, и в отчёте перед собственником цифра CLS сама по себе ничего не значит. Практический смысл шрифтовой оптимизации в трёх вещах.

Скорость до первого прочитанного слова. FOIT — это буквально секунды, когда посетитель смотрит на страницу без текста. На мобильном трафике из поиска, где терпение измеряется единицами секунд, это прямые отказы. Отказы на входной странице влияют на поведенческие факторы, а через них — на ранжирование.

Стабильность интерфейса. Сдвиг макета в момент, когда пользователь тянется к кнопке, — это мискликов и раздражение. На страницах с формами и корзиной это конвертируется в потери напрямую; связка «удобство → заявки» разобрана в статьях про юзабилити и SEO и конверсию сайта.

Устойчивость к плохим условиям. Значительная часть аудитории заходит с мобильного интернета переменного качества. Сайт, который в лаборатории показывает отличные цифры, а на 3G держит текст невидимым четыре секунды, теряет именно тех посетителей, за которых вы платите больше всего. Мобильная сторона вопроса подробно разобрана в материале про мобильную оптимизацию сайта.

И последнее по порядку, но не по важности: шрифтовые правки относятся к редкой категории задач с высоким соотношением эффекта к трудозатратам. Здесь не нужно менять архитектуру, переписывать бэкенд или согласовывать контент — почти вся работа умещается в правку @font-face, пересборку двух-трёх файлов и добавление нескольких строк в <head>. Это часто самая дешёвая точка входа в улучшение технических метрик на сайте, где всё остальное уже сделано.

Частые вопросы