Аудит веб-шрифтов в Lighthouse: как читать предупреждения

Аудит веб-шрифтов в Lighthouse показывает, как загрузка, отображение и кэширование шрифтов влияют на скорость страницы и стабильность интерфейса. Предупреждение не всегда означает критическую ошибку: его нужно сопоставить с водопадом Network, метриками LCP и CLS, фактическим размером файлов и сценарием использования начертания. Ниже разберём, что именно проверять и какие исправления действительно дают результат.

Lighthouse анализирует страницу в заданном сценарии и формирует рекомендации по производительности. Для веб-шрифтов важны не только отдельные пункты отчёта, но и последовательность событий: когда найден CSS, когда браузер обнаружил font-face, когда запросил файл, сколько длилась загрузка и изменился ли внешний вид текста после её завершения. Поэтому исправлять предупреждения механически, без проверки в браузере, не стоит.

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

Главная визуальная проблема называется FOIT — Flash of Invisible Text, когда текст временно скрыт до загрузки шрифта. Противоположный сценарий — FOUT, Flash of Unstyled Text: сначала виден запасной шрифт, а затем текст переключается на веб-шрифт. FOUT обычно лучше для доступности, но резкая смена ширины символов может вызвать скачок строк, изменение высоты блока и рост CLS.

Для оценки нужно разделять три задачи. Первая — сделать текст видимым как можно раньше. Вторая — уменьшить время и объём загрузки нужных файлов. Третья — подобрать резервный шрифт с похожими метриками, чтобы после замены не менялась геометрия макета. Хороший результат достигается сочетанием font-display, формата WOFF2, subset-файлов, корректного preload и долгого кэширования.

Аудит «Ensure text remains visible during webfont load» обычно указывает, что для одного или нескольких веб-шрифтов не задано подходящее свойство font-display. Без него браузер выбирает собственную стратегию отображения. В результате текст может быть невидимым заметное время или поздно заменяться загруженной гарнитурой. Проверять нужно каждое правило @font-face, а не только основной стиль страницы.

Для большинства интерфейсов отправная точка — font-display: swap. Браузер показывает резервный шрифт, а после загрузки применяет веб-шрифт. Значение optional позволяет браузеру отказаться от поздней замены на медленном соединении, а fallback задаёт короткий период ожидания и затем использует запасной вариант. Выбор зависит от роли шрифта: для основного текста важнее непрерывная читаемость, для декоративного заголовка допустима другая стратегия.

Пример исправления выглядит так: в правиле @font-face укажите font-display: swap, src с форматом WOFF2 и точное начертание через font-weight и font-style. Не объявляйте один файл как диапазон начертаний, если он содержит только обычное начертание: браузер может использовать неподходящий ресурс или сформировать синтетическое начертание.

Предупреждение «Preload key requests» появляется, когда важный ресурс обнаруживается слишком поздно или может быть загружен раньше. Для веб-шрифтов preload полезен только тогда, когда файл действительно нужен для первого экрана: например, одно начертание используется в главном заголовке или основном тексте сразу после открытия страницы. Предзагрузка всех файлов превращается в конкуренцию за пропускную способность и может замедлить более важные ресурсы.

В HTML для шрифта обычно задают rel="preload", as="font", type="font/woff2" и crossorigin, если ресурс загружается с другого происхождения или сервер требует CORS-режим. URL в preload должен в точности совпадать с URL в @font-face: различия в домене, параметрах, протоколе или относительном пути могут привести к двойному запросу. После изменения подключений снова проверьте Network и убедитесь, что ресурс не загружается дважды.

Lighthouse может связывать крупные файлы шрифтов с общим объёмом сетевых ресурсов или задержкой загрузки. Частая причина — один универсальный файл, в котором находятся кириллица, латиница, дополнительные символы, несколько начертаний и расширенный набор знаков. Если странице нужен только русский текст и два начертания, загрузка полного семейства нерациональна.

Используйте WOFF2 как основной современный формат для браузеров, которым он доступен, и готовьте отдельные subset-файлы для реально используемых наборов символов. Свойство unicode-range помогает браузеру выбирать подходящий файл для диапазона Unicode. Однако разбиение должно быть проверено на конкретном контенте: редкий символ, знак валюты или комбинируемый диакритический знак не должен неожиданно исчезнуть или перейти на другую гарнитуру.

Сокращение количества начертаний часто даёт больший эффект, чем агрессивное уменьшение одного файла. Начните с аудита макета: определите, нужны ли одновременно normal, medium, semibold и bold, используется ли курсив и действительно ли отдельный шрифт требуется для каждого компонента. Если браузер синтезирует жирность или наклон, результат может ухудшиться, поэтому решение нужно принимать после визуального сравнения.

Предупреждение «Serve static assets with an efficient cache policy» касается не только шрифтов, но для них особенно полезно. Веб-шрифт обычно меняется реже, чем HTML и JavaScript, поэтому его можно отдавать с длительным сроком хранения и версионировать имя файла при обновлении. Тогда повторный визит не требует скачивания прежнего ресурса, а новая версия не застревает в кэше.

Проверьте в Network заголовки ответа для WOFF2: браузер должен получать понятную политику Cache-Control, корректный Content-Type и успешный статус. Если шрифт размещён на CDN или отдельном домене, дополнительно проверьте CORS. Кэширование ускоряет повторные открытия, но не исправляет медленный первый визит, поэтому его нельзя считать заменой оптимизации критического пути.

Откройте DevTools, перейдите в Network, включите фильтр Font и перезагрузите страницу без использования кэша. Смотрите на время начала запроса, длительность ожидания, размер переданных данных, код ответа и инициатор. Если файл начинает загружаться только после большого CSS, проблема может быть в цепочке обнаружения. Если запрос быстрый, но шрифт долго применяется, исследуйте количество начертаний и особенности страницы.

Вкладка Performance помогает связать загрузку шрифта с отрисовкой текста и изменениями layout. Вкладка Coverage показывает, какие CSS-правила и ресурсы фактически не используются в сценарии. Если Lighthouse сообщает о лишнем ресурсе, но он нужен после открытия меню или перехода на другой маршрут, не удаляйте его без проверки пользовательского пути. Аудит всегда относится к конкретной загрузке, а не ко всему продукту.

Представим страницу, где подключены четыре начертания одного семейства, каждое одним полным файлом для всех языков. Lighthouse отмечает отсутствие font-display и рекомендует проверить критические запросы. В Network видно, что два шрифта загружаются до появления текста, а ещё два запрашиваются после открытия страницы. Пользователь сначала видит системный шрифт, затем заголовок меняет ширину и сдвигает кнопку.

Рациональное исправление состоит из нескольких действий: добавить font-display: swap, оставить для первого экрана только нужные начертания, подготовить WOFF2-subset с кириллицей и латиницей, предварительно загрузить одно критическое начертание и настроить долгий кэш для версионируемых файлов. После этого нужно сравнить не только балл Lighthouse, но и время появления текста, количество запросов, визуальные скачки и читаемость на медленном соединении.

Резервный шрифт должен быть не просто похожим по настроению, а близким по геометрии: ширине знаков, высоте строчных, насыщенности и межстрочному интервалу. Иначе после загрузки веб-шрифта меняется количество строк, высота карточек и положение кнопок. Сравнивайте длинные заголовки, абзацы на кириллице, цифры и элементы интерфейса, а не только короткое слово в макете.

CSS Font Loading API и font-size-adjust могут помочь точнее контролировать переход между гарнитурами, но применять их следует после базовой настройки. Сначала добейтесь корректного font-display, разумного набора файлов и стабильного кэширования. Затем проверьте реальный пользовательский сценарий: холодную загрузку, повторное открытие, медленную сеть, отключённый JavaScript и системные настройки увеличенного текста.

Нет, сначала определите влияние предупреждения на конкретную страницу. Рекомендация может относиться к редко используемому начертанию или сценарию, который не влияет на первый экран. Проверьте сетевой запрос, видимость текста, CLS и роль ресурса в пользовательском пути, а затем принимайте решение.

Для основного текста часто начинают с swap, потому что пользователь сразу получает читаемый контент. Optional может быть уместен для необязательного декоративного шрифта, когда поздняя замена создаёт больше проблем, чем пользы. Окончательный выбор зависит от отличий между резервной и основной гарнитурами и от сценария загрузки.

Нет. Preload стоит использовать для небольшого числа шрифтов, необходимых на первом экране. Если предварительно загрузить много файлов, они начнут конкурировать с HTML, CSS, изображениями и другими критическими ресурсами. Для второстепенных начертаний обычного обнаружения через CSS обычно достаточно.

Смена шрифта может изменить ширину строк и высоту текстовых блоков, особенно если резервная гарнитура заметно отличается по метрикам. Поэтому swap решает проблему невидимого текста, но не гарантирует отсутствие сдвигов. Подберите близкий fallback, настройте размеры и межстрочный интервал, а затем проверьте страницу в Performance.

Переход на WOFF2 обычно уменьшает сетевую нагрузку, но сам по себе не решает все проблемы. Нужно также убрать ненужные начертания, подготовить подходящие языковые подмножества, настроить font-display, кэширование и при необходимости preload. Кроме того, проверьте, что сервер правильно отдаёт MIME-тип и не создаёт повторных запросов.

Если крупный заголовок или текстовый блок является частью первого экрана, задержка шрифта может влиять на момент его полноценного отображения. Сопоставьте LCP в Lighthouse и Performance с моментом начала и завершения запроса шрифта. Если связь подтверждается, сократите цепочку обнаружения, уменьшите ресурс или измените стратегию отображения.

Предупреждения Lighthouse о веб-шрифтах нужно читать как подсказки для диагностики, а не как список безусловных запретов. Проверяйте font-display, критический путь, preload, формат WOFF2, subset, кэширование, резервную гарнитуру и реальные метрики CLS и LCP. Такой подход помогает улучшить не только отчёт, но и фактическое восприятие сайта.

Если вы создаёте собственный шрифт для сайта, заранее учитывайте кириллицу, нужные начертания, особенности интерфейса и веб-экспорт. Создайте шрифт на fontgenerator.ru и подготовьте типографическую основу, которую будет проще быстро и стабильно загружать в браузере.