Skip to content

Все для WordPress, веб-розробки — і не тільки

🔤 Попереднє завантаження шрифтів у WordPress: прибираємо попередження PageSpeed Insights

🔤 Попереднє завантаження шрифтів у WordPress: прибираємо попередження PageSpeed Insights

Коли ви проганяєте сайт через PageSpeed Insights, один із частих діагнозів, «Ensure text remains visible during webfont load». Українською це звучить як «Забезпечте видимість тексту під час завантаження вебшрифтів». Проблема знайома кожному, хто встановлював Elementor, Astra або підключав Google Fonts: поки браузер завантажує файл шрифту, текст на сторінці просто відсутній. Білий екран замість заголовка, долі секунди порожнечі, і відвідувач уже пішов.

Технічно це називається FOIT (Flash of Invisible Text). Корінь проблеми, у директиві font-display, яку браузер використовує за замовчуванням. Без явної вказівки font-display: swap браузер чекає на завантаження шрифту й не показує текст, доки файл не отримано. А якщо шрифт завантажується з CDN, через сторонній домен, затримка накопичується, і PageSpeed Insights фіксує попередження.

Вирішується це двома речами: по-перше, кожному @font-face потрібно додати font-display: swap, тоді браузер одразу покаже текст системним шрифтом і «підмінить» його на кастомний, коли той завантажиться. По-друге, критично важливі шрифти (той, яким набрано заголовок на першому екрані) варто попередньо завантажити через <link rel="preload">. Нижче, покроковий розбір, як зробити це у WordPress з урахуванням плагінів на кшталт Elementor і тем типу Astra.

💡 Швидкий огляд:

  • Відкриваємо звіт PageSpeed Insights і виписуємо проблемні шрифти з діагностики
  • Вимикаємо стилі плагінів і теми через wp_dequeue_style у functions.php
  • Копіюємо файли шрифтів у локальну папку й перестворюємо font-face із font-display: swap
  • Додаємо preload для одного-двох шрифтів першого екрана
  • Для користувацьких шрифтів Elementor змінюємо шлях на локальний і перезбираємо CSS

Крок 1: знаходимо проблемні шрифти у звіті

Запускаємо аудит на PageSpeed Insights, дочекавшись результату, знаходимо секцію діагностики. Нас цікавить пункт «Забезпечте видимість тексту під час завантаження вебшрифтів», в англійському інтерфейсі це «Ensure text remains visible during webfont load».

Список проблемних шрифтів у звіті PageSpeed Insights

Розгортаємо список, бачимо конкретні URL шрифтів, які не мають font-display: swap. Зазвичай це:

  • fontawesome-webfont.woff2, Font Awesome з Elementor;
  • eicons.woff2, іконковий шрифт Elementor;
  • Google Fonts (Open Sans, Roboto, Montserrat), якщо тема тягне їх через CDN.

Виписуємо назви файлів, вони знадобляться для наступних кроків. Головне зараз: зрозуміти, який плагін або тема відповідає за кожен шрифт. Font Awesome і eicons ідуть з Elementor. Google Fonts найчастіше підключає тема, в Astra це хук astra-google-fonts.

Крок 2: вимикаємо стилі, які тягнуть шрифти

Тепер завдання, прибрати стандартне підключення цих шрифтів, щоб потім повернути їх із правильними налаштуваннями. Йдемо у functions.php дочірньої теми (або в плагін із кодом на кшталт Code Snippets) і додаємо:

1/**
2 * Отключаем стили, загружающие проблемные шрифты
3 */
4function sdstudio_dequeue_font_styles()
5{
6 // Astra — Google Fonts
7 wp_dequeue_style('astra-google-fonts');
8 wp_deregister_style('astra-google-fonts');
9
10 // Elementor — Font Awesome 4
11 wp_dequeue_style('font-awesome');
12 wp_deregister_style('font-awesome');
13
14 // Elementor — eicons
15 wp_dequeue_style('elementor-icons');
16 wp_deregister_style('elementor-icons');
17}
18add_action('wp_enqueue_scripts', 'sdstudio_dequeue_font_styles', 9999);
19add_action('wp_head', 'sdstudio_dequeue_font_styles', 9999);

Пріоритет 9999 важливий: хук має відпрацювати ПІСЛЯ того, як плагіни й тема зареєстрували свої стилі. Якщо шрифт усе ще завантажується, перевірте, чи не викликає його інший плагін (наприклад, меню або форма зворотного зв’язку можуть підключати свою версію Font Awesome). Шукайте пошуком по файлах плагіна рядок wp_enqueue_style із відповідним handle.

Після додавання коду значок Font Awesome на сайті тимчасово зникне — це нормально. Ми повернемо його на кроці 4.

Крок 3: копіюємо файли шрифтів у локальну папку

Коли шрифт підключено через CDN або через плагін, браузер робить зайвий DNS-запит до стороннього домену. Локальний хостинг шрифтів знімає цю затримку. Алгоритм:

  • Знаходимо файли шрифтів у структурі плагіна. Для Font Awesome з Elementor шлях буде: /wp-content/plugins/elementor/assets/lib/font-awesome/fonts/. Для eicons: /wp-content/plugins/elementor/assets/lib/eicons/fonts/. Для Google Fonts завантажуємо .woff2 із Google Fonts CDN.

  • Створюємо папку /wp-content/fonts/ у корені сайту й копіюємо туди всі потрібні файли. Достатньо форматів .woff2 (сучасні браузери) і .woff (запасний варіант для старих).

  • Якщо шрифт був підключений темою через Google Fonts CDN, завантажуємо актуальний .woff2 вручну через пряме посилання або за допомогою плагіна OMGF (про нього нижче).

Тепер у кожного шрифту є локальний шлях виду /wp-content/fonts/fontawesome-webfont.woff2. Переходимо до найважливішого, підключення.

Крок 4: підключаємо шрифти з font-display: swap і preload

Стилі вимкнено, файли на місці. Тепер прописуємо @font-face із правильною директивою font-display: swap і додаємо preload для миттєвого завантаження. Код розміщуємо у functions.php через хук wp_head:

1/**
2 * Подключаем шрифты локально с font-display: swap и preload
3 */
4function sdstudio_inject_font_preload()
5{
6 ?>
7 <!-- Предзагрузка критических шрифтов -->
8 <link rel="preload" href="/wp-content/fonts/fontawesome-webfont.woff2" as="font" type="font/woff2" crossorigin="anonymous">
9 <link rel="preload" href="/wp-content/fonts/eicons.woff2" as="font" type="font/woff2" crossorigin="anonymous">
10
11 <style>
12 /* Font Awesome — иконочный шрифт */
13 @font-face {
14 font-family: 'FontAwesome';
15 font-display: swap;
16 font-style: normal;
17 font-weight: normal;
18 src: url('/wp-content/fonts/fontawesome-webfont.woff2') format('woff2'),
19 url('/wp-content/fonts/fontawesome-webfont.woff') format('woff');
20 }
21
22 /* eicons — иконки Elementor */
23 @font-face {
24 font-family: 'eicons';
25 font-display: swap;
26 font-style: normal;
27 font-weight: normal;
28 src: url('/wp-content/fonts/eicons.woff2') format('woff2'),
29 url('/wp-content/fonts/eicons.woff') format('woff');
30 }
31 </style>
32 <?php
33}
34add_action('wp_head', 'sdstudio_inject_font_preload', 5);

Пріоритет 5 у wp_head означає, що preload-теги стануть у <head> одними з перших, браузер почне завантажувати шрифт до того, як дійде до CSS. Атрибут crossorigin="anonymous" обов’язковий для preload шрифтів: без нього браузер проігнорує попереднє завантаження й завантажить файл повторно.

Важливий нюанс: в URL усередині @font-face не повинно бути query-параметрів на кшталт ?#iefix або ?v=4.7.0. PageSpeed Insights спотикається об них під час аналізу. Посилання має бути чистим: /wp-content/fonts/fontawesome-webfont.woff2, і все.

Після додавання коду скидаємо кеш (плагін кешування + Cloudflare, якщо використовується) і перепроганяємо PageSpeed Insights. Попередження про шрифти має зникнути. Іконки Font Awesome повертаються на місце, але тепер вони не блокують показ тексту.

Крок 5: користувацькі шрифти Elementor, особливий випадок

Якщо ви використовуєте Elementor Pro із функцією «Користувацькі шрифти» (Custom Fonts), логіка та сама, але є два додаткові кроки.

Перше, змінюємо шлях до шрифту в налаштуваннях Elementor. Заходимо в Elementor → Custom Fonts, відкриваємо потрібний шрифт і в полі URL вказуємо локальний шлях /wp-content/fonts/ваш-шрифт.woff2 замість зовнішнього CDN або посилання на Google Fonts:

Зміна шляху до файлу шрифту в налаштуваннях Elementor Custom Fonts

Друге, перезбираємо CSS Elementor. Після зміни шляху йдемо в Elementor → Tools → Regenerate CSS і натискаємо кнопку регенерації. Це змусить Elementor перебудувати файли стилів із новими шляхами до шрифтів:

Кнопка регенерації CSS в інструментах Elementor

Після регенерації перевіряємо, що в HTML сторінки шлях до шрифту веде на локальний файл, а не на CDN. Потім у header.php (або через wp_head як на кроці 4) додаємо preload для цього шрифту:

1<link rel="preload" href="/wp-content/fonts/FuturaBookC.woff2" as="font" type="font/woff2" crossorigin="anonymous">

І відповідний @font-face із font-display: swap:

1@font-face {
2 font-family: 'FuturaBookC';
3 font-display: swap;
4 font-style: normal;
5 font-weight: normal;
6 src: url('/wp-content/fonts/FuturaBookC.woff2') format('woff2'),
7 url('/wp-content/fonts/FuturaBookC.woff') format('woff');
8}

Альтернативний шлях: плагіни для автоматичної оптимізації

Ручний метод дає повний контроль, але потребує уваги під час оновлення плагінів (оновлення Elementor може повернути стандартне підключення шрифтів). Якщо хочете автоматизувати процес, ось два плагіни, які вирішують завдання без правлення коду.

OMGF (Optimize My Google Fonts). Безплатний плагін, який сканує всі Google Fonts на сайті, завантажує їх локально й додає font-display: swap автоматично. Встановлюєте, натискаєте «Optimize», і всі Google Fonts вашої теми перетворюються на локальні з правильними заголовками. Pro-версія вміє працювати з Adobe Fonts і будь-якими сторонніми CDN-шрифтами.

Swap Google Fonts Display. Мінімалістичний плагін, який робить рівно одне: додає font-display: swap до всіх Google Fonts на льоту. Не завантажує локально, але прибирає попередження PageSpeed Insights за 10 секунд встановлення. Підходить як тимчасове рішення або якщо локальний хостинг шрифтів не критичний.

Плагіни економлять час, але пам’ятайте: вони працюють тільки з Google Fonts. Іконкові шрифти (Font Awesome, eicons) і кастомні шрифти Elementor вони не чіпають, тут усе одно доведеться пройти ручні кроки 1-5.

⁉️🤔 Часті запитання

Чи потрібно попередньо завантажувати ВСІ шрифти сайту?

Ні. <link rel="preload"> має сенс тільки для одного-двох шрифтів, які потрапляють на перший екран, наприклад, шрифт заголовка H1 і шрифт основного тексту. Попереднє завантаження десятка шрифтів дасть зворотний ефект: браузер витратить смугу пропускання на файли, які не потрібні просто зараз, і сповільнить завантаження критичного контенту. Попередньо завантажуйте тільки шрифти, що використовуються у first viewport. Для типового блогу це один шрифт заголовка й один текстовий, разом два woff2-файли. Іконковий шрифт варто попередньо завантажувати, тільки якщо іконка є на першому екрані (меню, пошук). Усе інше підтягнеться в міру скролу без шкоди для метрик PageSpeed.

Що робити, якщо після вимкнення стилів сайт «поїхав»?

Найчастіший сценарій: вимкнули elementor-icons, і зникли стрілки слайдера або іконка пошуку. Рішення: перед вимкненням перевірте, які саме елементи використовують шрифт. Відкрийте DevTools (F12), вкладка Elements, знайдіть іконку й подивіться CSS-клас. Якщо клас починається з fa-, це Font Awesome. Якщо з eicon-, це eicons. Вимикайте тільки те, що реально використовується, і локально підключайте ті самі файли, візуально нічого не зміниться. Сайт «їде» у двох випадках: або ви вимкнули стиль, який окрім шрифту ніс CSS-правила (рідко, але буває з темами на кшталт Astra), або ви не підключили шрифт назад локально. У першому випадку витягніть CSS-правила з вимкненого файлу й скопіюйте їх у свій wp_head-блок. У другому, просто додайте відсутній @font-face.

Чи підходить метод для будь-якої теми WordPress?

Так, із застереженнями. Принцип dequeue style → local fonts → font-display: swap → preload універсальний. Змінюються тільки handle стилів: у Astra це astra-google-fonts, у GeneratePress це generate-fonts, у OceanWP це oceanwp-google-fonts. Щоб знайти handle вашої теми, відкрийте вихідний код сторінки (Ctrl+U), знайдіть <link rel="stylesheet" зі шрифтом і подивіться id тега — це і є handle. Далі підставте його в wp_dequeue_style. Сучасні теми (2024-2026) дедалі частіше додають font-display: swap з коробки: Twenty Twenty-Five, блокові теми на основі theme.json уже мають це налаштування. Перш ніж правити код, перевірте, можливо, ваша тема вже все робить правильно, а попередження викликає тільки іконковий шрифт окремого плагіна.

Чи обов’язково копіювати шрифти локально?

Технічно, ні. font-display: swap працює і зі шрифтами, підключеними через CDN (Google Fonts, cdnjs). Але локальний хостинг дає дві переваги: по-перше, ви прибираєте зайвий DNS-запит до стороннього домену (економія 50-200 мс), по-друге, ви не залежите від доступності CDN. Якщо Google Fonts ліг, ваш сайт залишиться з читабельним текстом. Для production-сайту локальний хостинг, правило гарного тону, для pet-проєкту, опціонально. Виняток: іконкові шрифти. Font Awesome, eicons, dashicons завантажуються з плагіна (локально за визначенням), їх копіювання в кореневу папку потрібне лише для того, щоб «перехопити» управління завантаженням після dequeue. Сам файл фізично вже на сервері.

Що робити з попередженням про шрифти: підсумковий алгоритм

Пройдіть п’ять кроків із цього гайду, і попередження «Ensure text remains visible during webfont load» зникне зі звіту PageSpeed Insights. Якщо коротко: вимикаєте стандартне підключення → кладете шрифти локально → повертаєте з font-display: swap → попередньо завантажуєте критичний woff2 → для Elementor додатково змінюєте шлях і перезбираєте CSS. На виході текст на сайті видно миттєво, метрики LCP і FCP покращуються, а відвідувач не бачить сторінки, що «стрибає».

Якщо не хочете копатися в коді, почніть із плагіна OMGF для Google Fonts. Для іконкових шрифтів плагіна-«таблетки» немає, їх усе одно доведеться обробляти руками, але це 20 хвилин роботи, яка окупається зростанням балів у PageSpeed і реальним прискоренням завантаження. Пробуйте й тестуйте після кожної зміни, тільки повторний аудит покаже, що проблему справді вирішено.