Подключение Google Fonts стандартным методом через API создает до 3 дополнительных DNS-запросов и увеличивает время отрисовки первого кадра (FCP) на 200–500 мс. В условиях Core Web Vitals такая задержка может стать критической для прохождения теста LCP, особенно на мобильных устройствах с 3G-соединением.
Проблема внешних запросов и Render-Blocking
Стандартный вызов шрифтов через fonts.googleapis.com заставляет браузер сначала установить соединение с сервером Google, скачать CSS-файл, а затем уже сами файлы шрифтов. Это создает цепочку зависимостей, которая блокирует рендеринг страницы. В среднем, один набор из 3 начертаний (Regular, Medium, Bold) добавляет от 150 до 400 КБ к общему весу страницы, если не ограничить выборку символов.
Кейс: при переходе с внешнего подключения на локальное хранение шрифтов на сайте из 50 страниц время отклика сервера (TTFB) не меняется, но показатель Cumulative Layout Shift (CLS) снижается на 0.1–0.2 единицы за счет исключения «скачка» текста при подгрузке шрифта. Мой вывод: любые внешние запросы к шрифтам в 2024 году — это неоправданная потеря производительности.
Локальное размещение: WOFF2 и сжатие
Единственный профессиональный метод оптимизации — загрузка шрифтов на собственный сервер в формате WOFF2. Этот формат обеспечивает сжатие на 30–50% эффективнее, чем WOFF или TTF. Например, файл шрифта Roboto в TTF весит около 120 КБ, тогда как WOFF2 того же начертания обходится в 30–45 КБ. Использование нескольких форматов (fallback) сегодня избыточно, так как поддержка WOFF2 составляет более 97% во всех актуальных браузерах.
Важный нюанс: многие плагины оптимизации делают это автоматически, но часто оставляют лишние начертания. Ограничение списка используемых весов (например, только 400 и 700 вместо всего диапазона от 100 до 900) сокращает объем передаваемых данных на 60–80%. Экспертный совет: удаляйте все начертания, которые не используются в дизайне, даже если они «могут пригодиться».
Управление отображением через font-display: swap
Одной из главных проблем является эффект FOIT (Flash of Invisible Text), когда пользователь видит пустой экран до загрузки шрифта. Свойство font-display: swap заставляет браузер мгновенно показать системный шрифт, а затем заменить его на Google Font после загрузки. Это сокращает время до первого отображения контента на 300–700 мс в зависимости от пинга.
Однако здесь кроется ловушка: если системный шрифт (например, Arial) сильно отличается по геометрии от выбранного Google Font, происходит заметный сдвиг контента, что бьет по метрике CLS. Чтобы этого избежать, я рекомендую подбирать системный шрифт-заменитель, максимально близкий по ширине символов. Это база для качественной оптимизации скорости WordPress для новичков и профи.
Оптимизация подмножеств (Subset) и кириллица
По умолчанию Google Fonts грузит огромный набор символов, включая латиницу, расширенную латиницу и спецсимволы. Для русскоязычного сайта достаточно подмножеств latin и cyrillic. Использование инструментов вроде Glyphhanger или онлайн-сервисов по обрезке шрифтов позволяет удалить неиспользуемые глифы, снижая вес одного файла с 40 КБ до 12–15 КБ.
Пример: оптимизация шрифта Montserrat для лендинга позволила сократить суммарный вес шрифтовых файлов с 210 КБ до 55 КБ без потери визуального качества. Вывод: ручная обрезка шрифтов под конкретный язык — это «золотой стандарт» для высоконагруженных проектов с жесткими требованиями по PageSpeed.
Вывод
Мой вердикт: полностью откажитесь от подключения Google Fonts через API. Единственно верный путь — локальное размещение в формате WOFF2, строгое ограничение начертаний (не более 3-х) и обязательное использование font-display: swap. Начинайте с установки плагина для локализации или ручного переноса файлов в папку /fonts/ и прописи @font-face в CSS. Избегайте использования более 2 разных семейств шрифтов на одной странице, так как каждый новый шрифт — это дополнительные 30–60 КБ и риск просадки LCP.
