Сайт гальмує, а GTMetrix показує 130+ HTTP-запитів на сторінку?

Це не абстрактна цифра зі звіту. Кожен запит — це звернення браузера до сервера за файлом: скриптом, стилем, зображенням, шрифтом. Що їх більше, то довше відвідувач дивиться на білий екран. За даними Portent, затримка завантаження з 0 до 3 секунд знижує конверсію на 2,5%. А кожна зайва секунда понад це, ще мінус 4,4%.

Проблема HTTP-запитів не в тому, що вони є. А в тому, що більшість сайтів на WordPress генерує їх у рази більше, ніж потрібно. Далі, п’ять конкретних кроків, які скорочують кількість запитів без переписування сайту з нуля.

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

• Видаліть невикористовувані плагіни та теми, які створюють зайві запити на кожній сторінці
• Оптимізуйте зображення: стисніть файли, приберіть невикористовувані картинки, об’єднайте іконки у спрайти
• Об’єднайте CSS і JavaScript в 1-2 файли та увімкніть мініфікацію
• Налаштуйте відкладене завантаження для скриптів, що блокують рендеринг сторінки
• Підключіть кешування та CDN, щоб повторні відвідувачі не завантажували сайт наново

Крок 1. Видаліть сміття

Кожен встановлений плагін тягне за собою файли. PHP, CSS, JavaScript, будь-який із них створює HTTP-запит під час завантаження сторінки. Плагінів двадцять штук, запитів уже під сотню просто на старті, до контенту.

Перше, що варто зробити,, аудит. Відкрийте Plugins → Installed Plugins і чесно дайте відповідь: які з них критичні для роботи сайту, а які висять «про всяк випадок»? SEO-аналізатор, який ви встановили рік тому і відкривали двічі,, кандидат на видалення. Плагін для вставки іконок соцмереж, теж, якщо ви й так вивели посилання у футері.

Окрема категорія, плагіни, які підключаються до сторонніх серверів. Live-чат, радіо, push-сповіщення. Кожен такий плагін створює додаткові зовнішні HTTP-запити до серверів третіх сторін. Видаліть усе, без чого сайт функціонує. Потрібен раз на місяць? Встановіть на день і видаліть.

Те саме правило працює для тем. У Appearance → Themes тримайте лише активну тему й одну запасну (наприклад, стандартну Twenty Twenty-Five). Решту, у кошик.

Якщо плагін потрібен, але лише на конкретній сторінці, завантажуйте його вибірково. Для цього є Asset CleanUp: Page Speed Booster, безплатний плагін зі 100 000+ активних установок і рейтингом 4,7 на WordPress.org.

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

🔗 Asset CleanUp на WordPress.org

До речі, заодно оптимізуйте базу даних: після чистки плагінів у таблицях залишаються налаштування й записи, які теж варто прибрати. І перевірте биті посилання, кожен редирект це зайвий HTTP-запит.

Щоб наочно побачити масштаб проблеми до і після, протестуйте сайт у GTMetrix:

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

Крок 2. Оптимізуйте зображення

Зображення, головна «вага» середньостатистичної сторінки WordPress. За даними HTTP Archive, на десктопі картинки займають близько 44% від загального обсягу сторінки. І кожне зображення — це HTTP-запит.

Почніть із видалення невикористовуваних файлів. У Media → Library відфільтруйте «Unattached» — це картинки, які не прикріплені до жодного запису. Якщо вони не використовуються в темі або у футері, видаляйте.

Далі, стиснення. Плагіни на кшталт WP Compress роблять це автоматично: під час завантаження зображення воно проганяється через хмарний оптимізатор, стискається без видимої втрати якості та конвертується у WebP або AVIF. Ці формати помітно легші за JPEG за тієї самої візуальної якості: за даними Google, WebP зменшує розмір файлу в середньому на 25-35% порівняно з JPEG.

У WP Compress 10 000+ активних установок, рейтинг 4,5 із 5 і понад 1,1 мільйона завантажень на WordPress.org. Перші 100 зображень безплатно, достатньо, щоб оцінити різницю.

🔗 WP Compress на WordPress.org

Стиснення саме по собі не зменшує кількість HTTP-запитів. Але воно знижує розмір кожного файлу, а отже, час на його передачу. У зв’язці з рештою кроків це дає відчутний приріст швидкості.

CSS-спрайти: один файл замість десяти

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

Принцип роботи: п’ять картинок, п’ять запитів до сервера. Ті самі п’ять картинок, зібрані в один спрайт,, один запит. Для створення спрайтів є онлайн-інструменти на кшталт CSS Sprite Generator. Знадобиться базове знання CSS, задати background-position для кожної іконки.

Зверніть увагу: якщо сервер підтримує HTTP/2, файли завантажуються асинхронно в межах одного з’єднання. У цьому разі економія від спрайтів менш помітна. Але на практиці десяток іконок одним файлом усе одно завантажується швидше, ніж десятьма окремими.

Крок 3. Об’єднайте та мініфікуйте CSS і JavaScript

Типова картина на WordPress-сайті: 40+ файлів JS і 20+ CSS. Кожен, окремий HTTP-запит. У сумі це 60+ звернень до сервера лише за скриптами й стилями, які завантажуються до показу контенту.

Мініфікація прибирає з файлів усе зайве: пробіли, перенесення рядків, коментарі. Файл стає легшим, але кількість HTTP-запитів не змінюється.

Об’єднання склеює кілька файлів в один. Було п’ять CSS, стало два (один для першого екрана, один для решти). П’ять JS, аналогічно. І запитів замість десяти залишається два-три.

Найпопулярніший безплатний інструмент для цього, Autoptimize. Плагін із мільйоном активних установок і рейтингом 4,7. У налаштуваннях, три позначки: оптимізувати HTML, CSS і JS. Вмикаєте всі три й отримуєте негайний результат.

Для тоншого налаштування є WP Rocket, преміумрішення, яке об’єднує файли, мініфікує їх і додає кешування в одному інтерфейсі.

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

🔗 WP Rocket на офіційному сайті

І ще раз: об’єднання файлів, не панацея. Якщо плагін підвантажує зовнішні скрипти з CDN (Google Fonts, reCAPTCHA, YouTube-плеєр), об’єднати їх не вийде. Їх можна лише відкласти або завантажувати асинхронно, про це, наступний крок.

Крок 4. Налаштуйте скрипти, що блокують рендеринг

Браузер читає сторінку згори вниз. Коли він зустрічає <script src="..."> у <head>, він зупиняє відтворення, завантажує скрипт повністю і лише потім продовжує. Відвідувач у цей час бачить порожню сторінку.

Рішення: перенести скрипти, які не потрібні для відтворення першого екрана, вниз сторінки або додати атрибут async/defer. Різниця:

• defer: скрипт завантажується у фоновому режимі, але виконується строго після парсингу HTML і в порядку підключення;
• async: скрипт завантажується і виконується за першої можливості, порядок не гарантовано.

Для WordPress є безплатний плагін Async JavaScript. Він додає async або defer до вибраних скриптів через зрозумілий інтерфейс. Працює з коробки, але потребує обережності: якщо скрипт, доданий через async, має виконатися раніше за інший, сторінка може зламатися.

Безпечний підхід: протестувати на одному скрипті, перевірити сайт в інкогніто, потім переходити до наступного.

WP Rocket також вміє відкладати скрипти: вкладка File Optimization → Load JavaScript deferred. Виберіть «Deferred» і додайте jQuery до винятків, адже більшість тем і плагінів WordPress від нього залежать.

Результат: сторінка починає відтворюватися раніше, навіть якщо загальна кількість HTTP-запитів не змінилася. Відвідувач бачить контент, поки решта скриптів довантажуються у фоновому режимі.

Крок 5. Підключіть кешування та CDN

Кешування напряму скорочує HTTP-запити під час повторних візитів. Механіка проста: браузер зберігає статичні файли (CSS, JS, зображення, шрифти) локально. При наступному відкритті сторінки замість запиту до сервера він бере файл із кешу. Нуль HTTP-запитів за цей файл.

Серверне кешування — це наступний рівень: сервер віддає вже зібрану HTML-сторінку замість того, щоб ганяти десятки PHP-запитів до бази даних. Плагіни кешування (WP Rocket, Flying Press, W3 Total Cache) роблять це автоматично.

CDN (Content Delivery Network) — це мережа серверів по всьому світу. Замість того щоб тягнути файли з вашого хостингу в Нідерландах для відвідувача з Бразилії, CDN віддає їх із найближчого до нього вузла. Плюс CDN-провайдери часто включають стиснення, мініфікацію та оптимізацію зображень «з коробки».

Cloudflare, безплатний варіант, який закриває базові потреби: CDN, захист від DDoS, безплатний SSL.

Встановіть плагін Cloudflare для WordPress, він зв’яже сайт із CDN і дасть базові налаштування прямо з адмінки. Для тоншого налаштування зайдіть у панель керування Cloudflare: увімкніть Auto Minify для CSS/JS/HTML, стиснення Brotli та Rocket Loader для асинхронного завантаження скриптів.

🔗 Cloudflare на WordPress.org

З кешуванням і CDN кількість HTTP-запитів для повторного відвідувача падає радикально. Перший візит, повне завантаження. Другий, більшість файлів віддається з браузерного кешу та найближчого CDN-вузла без звернень до вашого сервера.

Бонус: перевірте, чи підтримує сервер HTTP/2

HTTP/2 — це протокол, який передає кілька файлів через одне TCP-з’єднання. Браузер не чекає закінчення завантаження файлу №1, щоб запитати файл №2, вони вантажаться паралельно. Це знижує ефект від великої кількості HTTP-запитів: 60 файлів через HTTP/2 завантажуються швидше, ніж ті самі 60 через HTTP/1.1.

Перевірте свій сервер через інструмент KeyCDN HTTP/2 Test, введіть домен і натисніть «Test». Результат «HTTP/2 is supported» означає, що мультиплексування працює.

Якщо тест показує HTTP/1.1, зверніться до хостера. Більшість сучасних хостингів (SiteGround, Cloudways, Kinsta) включають HTTP/2 за замовчуванням. На shared-хостингах 2010-х років буває інакше. Заодно перевірте версію PHP: перехід на сучасну версію PHP дає помітний приріст продуктивності, а застарілі версії обробляють запити в рази повільніше. Якщо хостер не оновлює ані протокол, ані версію PHP, можливо, час задуматися про зміну хостингу.

Якщо віддаєте перевагу відеоформату, ось наочний посібник зі скорочення HTTP-запитів у WordPress (англійською, 12 хвилин).

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

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

Орієнтир, від 30 до 60 на сторінку. Усе, що вище 80-90, є приводом для оптимізації. GTMetrix і Pingdom показують конкретні цифри у своїх звітах. Після застосування п’яти кроків із цієї статті реально опуститися зі 130 до 35-45 запитів.

«У мене сайт на Elementor, там 100+ запитів і так. Це нормально?»

Конструктори сторінок генерують багато CSS і JS за своєю природою. Elementor і Divi додають 30-50 запитів самі по собі. Це не означає «змиритися» — це означає, що решта сайту має бути максимально чистою. Приберіть усе, що не стосується конструктора: зайві плагіни, зовнішні шрифти, неоптимізовані зображення. Залиште тільки те, що реально працює на відвідувача.

Що важливіше: кількість запитів чи загальний розмір сторінки?

І те, і інше. 20 запитів по 1 МБ кожен, сторінка вантажиться 20 секунд. 100 запитів по 5 КБ, може завантажитися швидше, але кожен запит створює накладні витрати на DNS, TCP-з’єднання і TLS-рукопотискання. На HTTP/2 ця різниця згладжується. На HTTP/1.1, критично. Оптимізуйте обидва параметри: скорочуйте кількість запитів через об’єднання файлів і спрайти, зменшуйте розмір через стиснення та мініфікацію.

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

Частково так. Мініфікацію CSS/JS можна налаштувати через Gulp або Webpack на етапі збірки теми. HTTP/2 вмикається на рівні сервера (конфігурація Nginx/Apache). Кешування, через серверні правила. Але для більшості власників WordPress-сайтів плагіни — це найпрактичніший шлях: налаштування за кілька хвилин, результат негайний, ризик зламати сайт нижчий.

Як часто потрібно перевіряти кількість HTTP-запитів?

Після кожного великого встановлення або оновлення плагіна. Новий плагін може додати свої CSS/JS на всі сторінки, і ви цього не помітите, поки сайт не почне гальмувати. Раз на місяць, достатня періодичність для рутинної перевірки. GTMetrix дозволяє налаштувати автоматичний моніторинг зі сповіщенням при падінні продуктивності.

Чи потрібен узагалі цей гайд, якщо в мене й так швидкий хостинг?

Хостинг вирішує частину проблеми на рівні сервера, але не на рівні коду. Якщо плагін вставляє 15 скриптів у <head> сторінки, навіть топовий сервер не змусить їх завантажитися миттєво. Браузер однаково чекатиме. Швидкий хостинг дає фору, але виграє той, хто чистить і клієнтську частину.

Що реально скорочує HTTP-запити, а що, ні?

Пройдімося по всіх кроках без ілюзій:

• Чистка плагінів і тем дає найпомітніший приріст. Кожен видалений плагін прибирає його CSS, JS і зовнішні виклики. На практиці після аудиту йде 10-30 запитів.
• Стиснення зображень: розмір файлів зменшується, кількість запитів не змінюється. Але сумарний час завантаження падає відчутно.
• Об'єднання CSS і JS сильно ріже кількість запитів. Мінус: може зламати верстку, перевіряйте після кожної зміни.
• Відкладене завантаження скриптів: запитів стільки ж, але сторінка стає видимою раніше.
• Кешування і CDN: для нових відвідувачів різниця мінімальна. Для повторних, повторне завантаження сторінки без жодного запиту до сервера.

Якби ми обирали рівно три дії, які дають найбільший ефект на типовому WordPress-сайті: (1) видалити непотрібні плагіни, (2) увімкнути об'єднання CSS/JS через Autoptimize, (3) поставити Cloudflare. Це три кроки, які займають вечір, а не тиждень, і які ви побачите в цифрах GTMetrix уже наступного дня.