Подключение Google Fonts стандартным методом через CDN добавляет к времени отрисовки страницы (LCP) от 200 до 800 мс из-за лишних DNS-запросов и TLS-handshake. В условиях Core Web Vitals это критическая потеря, которая может снизить конверсию на 2-5% при медленном соединении.
Проблема внешних запросов и Render-Blocking
Стандартный вызов шрифтов через fonts.googleapis.com заставляет браузер сначала связаться с DNS-сервером Google, установить соединение, и только затем загрузить файл шрифта. Это создает цепочку из 3-4 последовательных запросов. В итоге пользователь видит «скачок» контента (CLS), когда системный шрифт внезапно заменяется на дизайнерский через 0.5–1.2 секунды после загрузки.
Кейс: на сайте с 4 начертаниями Roboto время до первого отображения текста (FCP) составляло 1.8с. После перехода на локальные шрифты этот показатель упал до 1.1с. Экспертный вывод: любой внешний HTTP-запрос в критическом пути рендеринга — это неоправданный риск для SEO.
Локальный хостинг шрифтов как стандарт
Единственный способ полностью контролировать загрузку — скачать файлы в формате WOFF2 и разместить их на своем сервере. WOFF2 сжимает данные на 30-50% эффективнее по сравнению с WOFF или TTF. Для WordPress это означает исключение сторонних cookie-запросов, что также упрощает соблюдение GDPR.
Практический расчет: запрос к Google Fonts занимает ~300-500 мс. Локальный запрос к кэширующему серверу (Nginx/Litespeed) занимает 20-50 мс. Разница в 10 раз делает локальный хостинг безальтернативным при глубокой SEO оптимизации сайтов на WordPress.
Оптимизация через font-display: swap
Многие забывают про свойство font-display: swap в CSS. Без него браузер может скрывать текст до полной загрузки шрифта (FOIT), что катастрофически влияет на показатель LCP. С swap браузер сразу показывает системный шрифт, а затем мгновенно меняет его на целевой.
Нюанс: чтобы избежать сильного визуального сдвига (Layout Shift), необходимо максимально точно подобрать системный шрифт-заменитель (например, Arial для Roboto или Georgia для Times New Roman). Мой опыт показывает, что правильный подбор fallback-шрифта снижает показатель CLS с 0.15 до 0.02.
Предзагрузка критических начертаний
Использование <link rel="preload"> для основного шрифта заголовков позволяет начать загрузку файла еще до того, как браузер распарсит CSS-файл. Однако фатальная ошибка — предзагружать все 10-15 вариаций шрифта. Это забивает канал связи и замедляет загрузку основного контента.
Рекомендация: предзагружайте строго 1-2 самых важных файла (например, Bold для H1 и Regular для основного текста). Перебор с preloads увеличивает количество предупреждений в PageSpeed Insights и может даже замедлить отрисовку страницы на мобильных устройствах с 3G-соединением.
Инструментарий и автоматизация в WordPress
Для тех, кто не хочет править CSS вручную, существуют плагины вроде OMGF или функции в WP Rocket. Но будьте осторожны: автоматические плагины часто загружают лишние начертания (Italic, Light), которые вы даже не используете в дизайне, увеличивая вес страницы на 50-150 Кб.
Сравнение: ручная очистка шрифтов (оставление только 3 нужных весов) сокращает общий объем CSS и шрифтовых данных с 400 Кб до 80 Кб. Экспертный вывод: ручная оптимизация через @font-face всегда эффективнее любого плагина за счет исключения лишнего кода.
Вывод
Мой вердикт: полностью откажитесь от подключения Google Fonts через CDN. Переходите на локальный хостинг в формате WOFF2, используйте font-display: swap и предзагружайте только 2 основных начертания. Это единственный способ добиться «зеленой зоны» в Core Web Vitals по показателям LCP и CLS. Начинайте с аудита используемых весов: удалите всё, что не отображается визуально на сайте.