Skip to content

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

Як зменшити HTTP-запити в WordPress: аналіз та оптимізація

Як зменшити HTTP-запити в WordPress: аналіз та оптимізація

Сайт відкривається 4 секунди, і відвідувач пішов. Знайома ситуація?

За даними Google Research за 2023 рік, імовірність відмови зростає на 32% при збільшенні завантаження з 1 до 3 секунд. Одна з головних причин гальмування, яку часто пропускають,, надлишкові HTTP-запити. Вони не впадають в око, як важкі зображення чи поганий хостинг, але накопичуються десятками й у сумі з’їдають секунди.

Розберемо, що це за запити, як їх знайти через waterfall-аналіз у GTmetrix і, найголовніше, як скоротити їхню кількість без шкоди для функціональності сайту.

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

  • Відкриваєте GTmetrix, вставляєте URL сайту й переходите у вкладку Waterfall, бачите кожен запит із його розміром і часом завантаження
  • Фільтруєте запити за папками plugins і themes, знаходите плагіни, які тягнуть скрипти на всіх сторінках без потреби
  • Проходите за 5 пунктами: зайві зображення, необ’єднані CSS/JS, плагіни з глобальним завантаженням, важкі плагіни та відсутність лінивого завантаження
  • Після правок запускаєте тест повторно й порівнюєте кількість запитів «до» та «після»

Що таке HTTP-запити і чому вони гальмують сайт

Коли браузер відкриває сторінку, він не отримує готову картинку цілком. Йому потрібен HTML-каркас, файли стилів, кожен зі скриптів, шрифти, зображення, і для кожного елемента браузер надсилає окремий HTTP-запит до сервера.

Частина запитів іде на ваш сервер (внутрішні: зображення з медіатеки, тема, плагіни). Частина, на зовнішні сервіси (Google Analytics, YouTube-вбудовування, скрипти реклами). Браузер вибудовує їх у чергу й завантажує.

Залежність проста: більше запитів, довше завантаження. Але не всі запити однакові. Крихітний скрипт відстеження завантажується за 20 мс, а неоптимізоване зображення на 500 КБ може висіти пів секунди. Тому завдання не просто «скоротити кількість», а прибрати непотрібні й полегшити ті, що залишилися.

На практиці різниця помітна: сайт-портфоліо на чистій темі робить 18 запитів і відкривається миттєво. Великий новинний портал на кшталт New York Times, за 200 запитів, половина з яких, скрипти реклами та трекінгу. Ваш сайт десь посередині, і це число можна зменшити.

Як аналізувати HTTP-запити: waterfall у GTmetrix

Найнаочніший спосіб побачити HTTP-запити, waterfall-діаграма (каскад). Вона показує кожен запит окремим рядком: звідки, скільки важить, коли почав завантажуватися і скільки це тривало.

Інструменти, які вміють waterfall:

  • Вбудовані Chrome DevTools (вкладка Network), безплатно, але тільки для вашого браузера
  • GTmetrix, безплатний тариф, тест із різних локацій, зрозумілий інтерфейс
  • Pingdom Tools, схожий на GTmetrix, інші точки тестування
  • WebPageTest, максимум деталей, але складніший для початку

Розберемо на прикладі GTmetrix. Вставляєте URL, запускаєте тест. У результатах вкладка Waterfall, вона і є каскад:

Вкладка Waterfall у GTmetrix із загальною кількістю запитів

Сама діаграма має такий вигляд:

Waterfall-діаграма HTTP-запитів сайту в GTmetrix

Що означають стовпці:

  • URL, шлях до файлу. З нього видно, який плагін або тема додали запит
  • Домен, ваш сервер або зовнішній. Одразу видно, скільки завантажується ззовні
  • Розмір, вага файлу. Важкі запити сильніше б’ють по швидкості
  • Часова шкала, коли почався запит і як довго тривав. Важливий не лише розмір, а й положення: файл на початку ланцюжка блокує все, що йде за ним

Натисніть на поле пошуку над діаграмою та введіть wp-content/plugins, побачите лише запити від плагінів. На прикладі нижче плагін Lightweight Social Fonts додає запит шрифту fontello.woff на 22,9 КБ:

Фільтр запитів за папкою плагінів у GTmetrix Waterfall

А якщо відфільтрувати за themes, побачите запити теми. GeneratePress, наприклад, віддає всього 4 запити — це хороший показник для легкої теми:

HTTP-запити теми GeneratePress у waterfall GTmetrix

Пройдіться списком і поставте собі запитання: «Цей плагін справді потрібен на кожній сторінці?» Часто відповідь, ні. Далі розберемо, що з цим робити.

5 Способів скоротити HTTP-запити у WordPress

Після waterfall-аналізу у вас на руках список запитів. Тепер конкретні кроки для скорочення.

1. Прибрати зайві та непідготовлені зображення

Кожне зображення = один HTTP-запит. Якщо на сторінці 15 картинок, і 5 із них декоративні або дублюються — це 5 запитів, які можна прибрати без втрати сенсу. Для обов’язкових зображень правило інше: стиснути та підігнати під розмір відображення. Картинка 2500px, вставлена в блок шириною 700px, вантажить у 5 разів більше даних, ніж потрібно.

На практиці допомагає зв’язка: ручна ревізія (прибрати непотрібне) + плагін стиснення. Серед актуальних варіантів: ShortPixel, Imagify, Smush. Вони стискають зображення під час завантаження в медіатеку та можуть перетиснути наявні.

2. Об’єднати CSS і JavaScript

Тема та кожен плагін додають свої файли стилів і скриптів. Якщо у вас активна тема, 10 плагінів і пара зовнішніх сервісів, легко набирається 30-40 окремих CSS/JS-файлів. Кожен із них потребує окремого HTTP-запиту.

Техніка називається конкатенацією (об’єднанням) і зазвичай іде в парі з мініфікацією, видаленням пробілів і коментарів із коду. Більшість плагінів продуктивності роблять і те, і інше:

  • WP Rocket, преміум-плагін, об’єднує та мініфікує CSS/JS за пару кліків
  • Autoptimize, безкоштовний, тільки конкатенація та мініфікація

Важливо: після ввімкнення об’єднання пройдіться основними сторінками сайту та переконайтеся, що верстка не поїхала. Іноді скрипти конфліктують під час склеювання, тоді конкретний файл виключають з об’єднання.

3. Заборонити плагінам завантажуватися там, де не потрібно

Контактна форма стоїть лише на сторінці контактів. Але її CSS і JS часто завантажуються на всьому сайті — це 2-3 зайвих запити на кожній сторінці без форми. Contact Form 7, наприклад, за замовчуванням завантажує скрипти глобально.

Якщо плагін це допускає, є два шляхи:

  • Замінити на більш оптимізований аналог, який не вантажить ресурси глобально
  • Залишити плагін, але керувати завантаженням скриптів через Perfmatters, у ньому є менеджер скриптів, що дає змогу вимкнути CSS/JS плагіна на всіх сторінках, окрім тих, де він реально використовується

Результат: ті самі 2-3 запити, але лише на одній сторінці контактів, а не на всьому сайті.

4. Замінити важкі плагіни на легкі аналоги

Після waterfall-фільтра за plugins ви бачите, які плагіни генерують найбільше запитів. Якщо один плагін додає 8 скриптів і стилів, а його аналог обходиться двома, заміна скорочує 6 HTTP-запитів.

Приклади замін із практики:

  • Слайдер Revolution Slider (важкий) → легкий блок обкладинки з теми або MetaSlider
  • Конструктор сторінок з десятками скриптів → нативний редактор блоків Gutenberg
  • Плагін соцмереж із зовнішніми запитами до API → статичні іконки посилань

Перевірте кожен плагін зі waterfall-списку: чи використовується він узагалі? Якщо плагін не оновлювався понад рік або функціональність не потрібна, видаліть повністю.

5. Увімкнути ліниве завантаження

Ліниве завантаження (lazy loading) відкладає завантаження зображень та iframe, які розташовані нижче видимої області екрана. Відвідувач відкриває сторінку, завантажується лише те, що він бачить. Решта підтягується в міру прокручування.

З WordPress 5.5 атрибут loading="lazy" додається до зображень автоматично. Цього достатньо для базового сценарію. Якщо потрібне агресивніше ліниве завантаження (для iframe, фонових зображень, відео), використовуйте Perfmatters, WP Rocket або безкоштовний LazyLoad by WP Rocket.

Відео: HTTP-запити WordPress за 5 хвилин

Коротке відео на тему, від діагностики до скорочення запитів без плагінів:

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

Скільки HTTP-запитів, норма для WordPress?

Універсального числа немає. Чистий сайт на легкій темі з 5-7 плагінами вкладається в 25-40 запитів. Сайт із конструктором сторінок, рекламними скриптами й десятком плагінів може робити 80-120. Орієнтуйтеся не на абсолютне число, а на динаміку: було 90, стало 55, це хороший результат.

Чи впливають зовнішні запити (Google Fonts, Analytics) на швидкість?

Впливають, але інакше. Зовнішній запит до Google Fonts додає 1-2 запити, але вони йдуть через CDN Google і завантажуються швидко. Головна проблема, блокування рендерингу: поки шрифт не завантажиться, браузер може не показувати текст. Рішення: попереднє завантаження шрифтів через preload або хостинг шрифтів локально.

Чи обов’язково об’єднувати всі CSS і JS в один файл?

Не завжди. Об’єднання всіх скриптів в один файл дає один запит, але великий файл завантажується довше. Сучасний HTTP/2 вміє завантажувати кілька файлів паралельно, тому 3-4 файли по 30 КБ можуть завантажитися швидше, ніж один на 120 КБ. Оптимально об’єднувати критичний CSS (той, що потрібен для відтворення першого екрана) і залишати некритичні скрипти окремо з атрибутом defer.

Що робити, якщо після об’єднання CSS зламалася верстка?

Виключити проблемний файл з об’єднання. WP Rocket і Autoptimize дозволяють додати URL скрипта або стилю до списку винятків. Після цього запустіть тест заново, втрата одного файлу з пулу в 15 запитів майже непомітна.

Чи можна скоротити запити без плагінів?

Можна. Ручне deregister-ування скриптів через functions.php дає повний контроль, але потребує розуміння WordPress-хуків. Для більшості власників сайтів WP Rocket або Perfmatters простіше й безпечніше: вони не дадуть вимкнути критичний для роботи скрипт.

Пора навести лад у запитах

HTTP-запити — це не та річ, яку лагодять один раз. Поставили новий плагін, змінили тему, додали рекламний скрипт, з’явилися нові запити. Раз на пару місяців заходьте в GTmetrix, відкривайте Waterfall і звіряйтеся з тим, що було минулого разу.

Якщо прямо зараз не знаєте, скільки запитів робить ваш сайт, відкрийте GTmetrix, вставте URL і натисніть «Start Test». За хвилину побачите реальну картину. А далі, за кроками зі статті. Кожен прибраний запит наближає сайт до завантаження за 1-2 секунди.