Що я реально роблю, коли WordPress повільно вантажиться: мій базовий чекліст швидкості у 2026

Фраза “WordPress повільний” майже ніколи не означає одну конкретну проблему.
Зазвичай це суміш теми, плагінів, зображень, шрифтів і хостингу, плюс кілька “історичних” рішень, про які вже всі забули.

У цій нотатці я не буду радити “просто поставте кеш‑плагін”.
Замість цього покажу свій базовий чекліст, з якого я починаю, коли беруся за повільний WordPress‑сайт у 2026 році.

Крок 1. Спочатку міряємо, потім оптимізуємо

Перед тим як щось міняти, мені потрібно побачити цифри:

• відкриваю сайт у Chrome і дивлюся Lighthouse / PageSpeed Insights;

• у Search Console перевіряю Core Web Vitals для реальних користувачів (LCP, INP, CLS);

• у DevTools → Network дивлюся,

  • скільки важить сторінка,

  • скільки запитів JS/CSS,

  • що найповільніше відповідає.

Мета на цьому етапі — не “отримати 100/100”, а зрозуміти:

• де саме з’їдається час до першого значимого контенту (LCP);

• чи не вбивають сайт великі JS‑бандли (INP);

• чи немає дергань верстки (CLS).

Без цієї картини будь’які оптимізації — стрільба навмання.

Крок 2. Тема: що саме я перевіряю

Якщо Core Web Vitals показують проблеми, перше, куди я дивлюся, — тема.

Що я перевіряю:

• Скільки CSS і JS підключає тема на типовій сторінці.

  • Чи є кілька великих theme.js / vendor.js на кожній сторінці.

  • Чи немає застарілих бібліотек, які можна прибрати.

• Чи немає важких анімацій / слайдерів / hero-відео вгорі сторінки.

• Як організовані шаблони:

  • чи не тягнуться всі можливі скрипти всюди,

  • чи можна винести щось тільки на потрібні сторінки.

На практиці це часто означає:

• відключити зайві скрипти через wp_dequeue_script там, де вони не потрібні;

• прибрати “важкий” hero-слайдер і замінити на статичне зображення;

• розділити один величезний main.js на частини й завантажувати їх умовно.

Крок 3. Плагіни: хто реально винен у повільності

Другий шар проблем — плагіни.

Зазвичай я роблю так:

1. Дивлюся список активних плагінів і відразу помічаю “важку класику”: великі page builder’и, візуальні слайдери, десяток SEO / analytics додатків.

2. У DevTools / вкладці Network дивлюся, які JS/CSS файли належать яким плагінам.

3. Перевіряю, чи можна:

   • замінити частину функціональності на легший плагін;

   • відключити частину модулів усередині плагіна;

   • обмежити завантаження скриптів лише потрібними сторінками.

Часто достатньо:

• відмовитись від одного-двох “універсальних” плагінів на користь вузьких утиліт;

• прибрати дублікати (два плагіни, які роблять те саме);

• налаштувати умовне завантаження скриптів (наприклад, форми — тільки там, де вони є).

Крок 4. Картинки, шрифти, відео

Навіть ідеальна тема й помірна кількість плагінів не врятують, якщо:

• картинки заливаються у 3000 px прямо в hero;

• кожна секція має своє фонове фото “для краси”;

• на сторінку підключено 3–4 web-шрифти з купою варіацій.

Що я роблю тут:

• Визначаю ключові зображення (hero, карточки, галереї) й оптимізую їх:

  • розмір по ширині під макет,

  • сучасний формат (WebP/AVIF, якщо можливо),

  • коректні width/height і loading="lazy" де доречно.

• Переглядаю шрифти:

  • скільки різних сімейств і варіантів ваг;

  • чи можна залишити 1–2 гарні пари замість зоопарку.

• Якщо є відео в hero, намагаюся винести його далі вниз або замінити на постер / статичне зображення.

Це одна з тих зон, де можна швидко виграти 0.5–1 секунду LCP без великих рефакторингів.

Крок 5. Кеш, хостинг і “базова гігієна”

Лише після теми, плагінів та медіа я дивлюся на:

• Хостинг — час відповіді сервера, чи є HTTP/2/3, чи немає “задихаючогося” shared плану.

• Кешування — чи є нормальний page cache / object cache, чи немає конфліктів кількох кеш плагінів.

• Базові налаштування WordPress — чи немає купи застарілих ревізій, автозбережень без контролю, перевантажених cron‑подій.

Тут немає магії: інколи варто простопереїхати на нормальний хостинг або налаштувати один зрозумілий кеш‑плагін замість трьох.

Міні-кейс: було 3–4 секунди, стало менше двох

Щоб це не звучало абстрактно, короткий реальний приклад (без назв):

• Сторінка: головна корпоративного сайту на WordPress.

• Початковий стан:

  • LCP ~3.5–4 s на мобільному,

  • ~130 запитів,

  • важкий hero‑слайдер + кілька анімацій,

  • 20+ активних плагінів.

Що ми зробили в першу чергу:

1. Тема

   • викинули слайдер з hero, замінили на одну статичну картинку;

   • відключили пару декоративних анімацій, які нічого не давали по суті.

2. Плагіни

   • прибрали один великий “універсальний” плагін, функції якого частково дублювали тему;

   • винесли форму з важкого form-builder’а на легший варіант.

3. Медіа і шрифти

   • перевигрузили ключові картинки у WebP з адекватною шириною;

   • зменшили кількість шрифтів і варіантів ваг.

Результат після цих трьох кроків:

• LCP на мобільному просів до ~1.7–1.9 s;

• кількість запитів скоротилася помітно;

• без жодних агресивних “хакаємо все” оптимізацій.

Пізніше вже донастроїли кеш і кілька дрібниць, але найбільший прогрес дав саме цей базовий чекліст.

Коли базового чекліста замало

Буває й таке, що:

• сайт давно живе на складному стеку;

• є кастомні інтеграції, власні плагіни, нетипова логіка;

• performance‑проблеми сидять у нестандартних запитах до бази чи важкому custom-коді.

У таких випадках доводиться копати глибше: профілювати запити, аналізувати PHP‑код, іноді частково переробляти архітектуру теми чи плагінів.

Але майже завжди я починаю саме з цього простого чекліста.
Якщо його чесно пройти, то в більшості проєктів уже на цьому етапі можна відчути різницю — і в Core Web Vitals, і просто на очі.