Вариативные шрифты и Core Web Vitals: когда большой файл работает против вас

Вы заменили три статичных шрифта по 16 КБ одним вариативным. Файл весит 290 или 380 КБ — а то и все 640 КБ, если вы взяли Adobe Variable Concept с полным набором осей и кириллицей. В PageSpeed Insights вы ждали «зеленую зону», а получили 49 баллов на мобильных и LCP за 4 секунды.

Почему так вышло?

Потому что вы поверили в миф.

Тот самый, который кочует из статьи в статью: «Один файл — выше скорость». Звучит логично, только вот на реальном «железе», особенно на мобильных устройствах, эта математика ломается с треском. И я вам сейчас покажу, где именно.

Когда фондри отдают вариативный файл, они упаковывают туда всё: латиницу, расширенную кириллицу, диакритику, греческий, sometimes вьетнамский. Для кириллических шрифтов это оборачивается двукратным ростом числа глифов по сравнению с чисто латинскими версиями. Отсюда 400–600 КБ на ровном месте — вы платите трафиком за буквы, которые ваш лендинг не покажет никогда.

Миф об «одном запросе», который стоил вам конверсии

Давайте сразу к цифрам. Не к абстрактным «стало лучше», а к конкретике. Я взял три сценария для шрифтового семейства, которое используется на типичной контентной странице, и сравнил время загрузки:

Чувствуете разницу? Браузер не может начать рисовать текст, пока не скачает и не распарсит этот жирный файл. Не 380 килобайт — это еще не так страшно. А вот когда дизайнеры берут что-то вроде некоторых «дизайнерских» гарнитур или вариативный Roboto Flex — там уже 487 КБ. Или Source Sans Pro Variable — 405 КБ. Всё это превращается в критический ресурс, блокирующий отрисовку.

Задержка важнее объема

А теперь самое интересное — и самое непонятное для новичков.

Проблема не только в размере файла. Она в том, как браузер выстраивает приоритеты загрузки. Один файл на 300 КБ с font-display: swap — это гарантированный FOUT (вспышка нестилизованного текста), которую пользователь увидит на slow-соединении. Три статичных файла по 16 КБ с font-display: optional могут не вызвать никакой вспышки, потому что браузер успеет подхватить первый, самый важный шрифт, почти мгновенно.

Диагностика: откройте DevTools, вкладка Network, поставьте троттлинг «Slow 3G». Если ваш шрифт висит в очереди больше секунды — вы теряете посетителей. LCP — это Largest Contentful Paint, а крупнейший контент на лендинге — это, как правило, заголовок, набранный вашим кастомным шрифтом. И пока он висит в статусе «pending», Google считает, что страница не загрузилась.

«Но Google Fonts обещали 82% экономии…»

Да, в одном старом исследовании на Google Fonts фигурирует цифра экономии в 82% времени загрузки. Ключевое слово — «времени». И там же, мелким шрифтом, указано: «при 5+ начертаниях». А не при двух-трех.

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

Но в реальном мире, при HTTP/2, задержка уже не играет такой роли. Браузер может открыть одно соединение и скачать все нужные файлы параллельно. И вот тут-то и вылезает ахиллесова пята вариативных шрифтов: огромный размер одного файла при HTTP/2 нивелирует всю выгоду от экономии на рукопожатиях.

Тихий убийца: парсинг GSUB/GPOS на слабых устройствах

Размер — это еще цветочки. Ягодки начинаются, когда браузер начинает парсить скачанный файл.

Вариативный шрифт хранит не просто готовые глифы на каждую букву для каждого веса. Он хранит математические интерполяции, которые указывают, как «перетекает» форма знака от Thin к Black. Эти инструкции — особенно для сложных осей вроде CASL (casual) или slnt (slant) — требуют ресурсов.

На десктопном Core i9 вы этого не заметите. А на бюджетном Android-смартфоне за 150 долларов, которым пользуется каждый третий ваш посетитель, парсинг такого файла легко отъедает 200-300 мс от общего времени блокировки основного потока (TBT). И это прямое попадание в метрику FID (First Input Delay), а теперь и INP (Interaction to Next Paint).

Проверить это просто: откройте Performance-таб в Chrome DevTools, запустите запись на троттлинге CPU (4x slowdown). Если после «Parse Stylesheet» вы видите провал в кадрах — проблема именно в этом.

Когда variable font — это точно зло

Я выделил три железобетонных сценария, когда вариативный шрифт ухудшит показатели:

1. Нужно 2-3 начертания. Для комбинации Regular + Bold (или Regular + Bold + Italic) статические сабсеты будут весить в разы меньше. Я регулярно вижу проекты, где после замены одного вариативного файла на три статичных сабсета общий вес падает с 380 КБ до 45 КБ.
2. Многоязычный сайт. Если вы тянете вариативный шрифт с полной кириллицей, латиницей, диакритикой и греческим — вы везете мертвый груз. unicode-range не спасает, потому что браузер все равно качает весь файл, а потом разбирается, что ему нужно.
3. Выше всего — конверсия. Для лендингов, где каждая сотая секунды загрузки конвертируется в деньги, variable font на 640 КБ — это сознательный саботаж.

✅ А когда variable font — спасение

Я не хочу, чтобы вы подумали, будто я против variable fonts. Я «за», когда это оправдано:

• Вам нужно 5 и больше начертаний. Вот тут Google не врет: экономия достигает 70-88%, особенно если вы используете оси ширины (wdth) или оптического размера (opsz).
• У вас веб-приложение с микротипографикой. Когда через CSS-переменные (font-variation-settings) вы анимируете жирность заголовка от 400 до 700 при наведении — это работает красиво и нативно. Статическими шрифтами вы такого не сделаете без дерганой смены классов.
• Динамическая локализация. Если ваш интерфейс подстраивается под размер контейнера (конденсация текста в узких блоках), вариативная ось wdth решает задачу без шаманства с transform: scaleX().

Как провести аудит и перестать гадать

Хватит спорить в курилке. Вот алгоритм действий, который я даю своим командам. Сделайте это сегодня:

1. Откройте Network в DevTools, отфильтруйте по слову font.
2. Посмотрите суммарный вес всех .woff2. Если он больше 100 КБ — это первый звоночек.
3. Сравните с альтернативой: вырежьте из макета все используемые веса (только те, что реально есть в верстке!).
4. Скачайте статические версии этих начертаний и прогоните через glyphhanger (инструмент командной строки), оставив только латиницу и кириллицу.
5. Сравните новый суммарный вес с текущим вариативным.

Если разница больше, чем в 2 раза в пользу статики — решение очевидно.

⚡️ Совет: Для Google Fonts используйте параметр text= в URL, чтобы запрашивать только нужные символы. Например, ?text=HelloWorld вернет шрифт, содержащий только эти буквы. Это радикально ускоряет загрузку.

Что в итоге?

Меня бесит, когда хайп и маркетинговые материалы фондри заменяют людям голову. Variable fonts — это мощнейший инструмент. Но, как и любой мощный инструмент, он требует инженерного мышления, а не слепого следования моде.

В 8 случаях из 10 для среднего корпоративного сайта или лендинга правильно нарезанные статические сабсеты дадут лучший User Experience и лучшие показатели Core Web Vitals. Потому что покупатель с дешевого смартфона в метро не обязан ждать, пока скачается и распарсится ваш дизайнерский шедевр с 900 начертаниями. Ему нужно купить. И если кнопка «Купить» не отрисовалась за 2 секунды — он купит у конкурента.

Проверьте свои шрифты. Прямо сейчас. Ваша прибыль скажет вам спасибо.

24.05.2021