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

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

Нижче, 21 конкретний прийом, який ми застосовуємо на власних проєктах. Частина з них дає миттєвий ефект, частина працює у звʼязці. Усі перевірені на живих сайтах із реальним трафіком.

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

• Виміряйте вихідну швидкість через GTmetrix, вам потрібна точка відліку та розуміння вузьких місць
• Почніть із серверної бази: хостинг, PHP 8.3, стиснення GZIP і CDN, вони дають левову частку прискорення
• Встановіть плагін кешування та обʼєднайте скрипти/стилі, кількість HTTP-запитів впаде в рази
• Оптимізуйте медіа: стисніть зображення, приберіть зайві шрифти, закодуйте favicon у base64
• Вимкніть усе, чим не користуєтеся: невикористовувані плагіни, пінгбеки, емодзі WordPress, дублювальні запити від конструкторів

З чого почати: вимірюємо швидкість правильно

Перш ніж щось виправляти, треба побачити цифри. Найзручніші безплатні інструменти, GTmetrix і Pingdom. Вони дають не абстрактний бал, а конкретні метрики: час повного завантаження, загальний розмір сторінки та кількість HTTP-запитів. GTmetrix додатково показує «водоспад», візуальний графік завантаження кожного елемента, де одразу видно, що гальмує.

Ми в редакції віддаємо перевагу GTmetrix за прозорий інтерфейс і можливість тестувати з різних регіонів (після реєстрації). Ключові параметри, на які дивимося:

• PageSpeed Score і YSlow Score, оцінка оптимізації фронтенду. Високий бал не гарантує миттєвого завантаження, але низький означає, що резерв для покращень є.
• Fully Loaded Time, реальний час повного завантаження. Саме він впливає на поведінку користувача, а не бал. Для серверів у Європі/США нормою вважається ≤2 с; для азійського регіону з Європи цифра буде вищою, враховуйте географію аудиторії.
• Total Page Size, що менше, то краще. Для середньої сторінки блогу орієнтир, до 1 МБ.
• Requests, кількість запитів до сервера. Кожен зайвий запит = затримка. На добре оптимізованій домашній сторінці їх може бути 7-10.

Вкладки GTmetrix: де шукати вузькі місця

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

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

Вкладка Timings, дивимося на TTFB (Time to First Byte). Це час від запиту браузера до першого байта відповіді сервера. Google рекомендує тримати TTFB нижче 300 мс. Якщо у вас 800-1000 мс, проблема в хостингу або відсутності кешування, а не в зображеннях.

Сервер та інфраструктура: база швидкого завантаження

Серверна частина дає левову частку загального прискорення. Якщо тут усе погано, решта прийомів лише згладять картину.

Хостинг і розташування сервера

Вибір хостингу, не те місце, де варто економити. Провайдери на кшталт A2 Hosting і SiteGround тримають час відгуку низьким і пропонують дата-центри в США, Європі та Азії. Головне правило: сервер має бути географічно близько до цільової аудиторії. Для Європи, європейський дата-центр, для США, американський. Якщо аудиторія світова, рятує CDN (див. нижче).

Версія PHP

WordPress сьогодні вимагає щонайменше PHP 7.4, а рекомендований мінімум із 2025 року, PHP 8.3. Перехід із 7.4 на 8.3 дає приріст швидкості в 1,5-2 рази на чистому PHP-коді — це безплатне прискорення, яке багато хто ігнорує. Версію PHP змінюють у панелі хостингу (cPanel: Select PHP Version) або через звернення до підтримки. Перед зміною переконайтеся, що тема та плагіни сумісні, у 2026 році переважна більшість популярних плагінів уже підтримують 8.3.

Стиснення GZIP

GZIP стискає HTML, CSS і JavaScript на сервері перед надсиланням у браузер, обсяг переданих даних зменшується на 60-80%. Вмикається однією галочкою в плагіні кешування (Swift Performance, WP Rocket) або парою рядків у .htaccess для Apache. Це не опція, а стандарт, без GZIP сайт не пройде перевірку PageSpeed Insights.

CDN: Cloudflare і BunnyCDN

Мережа доставки контенту кешує статику (зображення, CSS, JS) на десятках серверів по всьому світу й віддає користувачеві з найближчого вузла. Рекомендуємо зв'язку: Cloudflare (базовий тариф безкоштовний) для загальних завдань + BunnyCDN для розвантаження медіафайлів. Разом вони закривають і географічну проблему, і захист від хотлінкінгу (через Cloudflare Scrape Shield), і кешування статики.

Плагіни та кешування: наводимо лад

Кешувальний плагін

Кеш-плагін генерує статичні HTML-копії сторінок і віддає їх замість запуску PHP під час кожного візиту. Різниця, як між читанням готової книги та переписуванням її від руки для кожного читача.

Плагін Swift Performance закриває одразу кілька пунктів нашого списку: кешування, об'єднання та мініфікацію скриптів/стилів, оптимізацію бази даних, відкладене завантаження, критичний CSS і локальний хостинг шрифтів. Встановити й налаштувати можна за 10 хвилин, базовий режим «Auto» дає 80% результату без ручного підбору параметрів.

Мініфікація та об'єднання скриптів

Кожен плагін WordPress може підвантажувати свої CSS і JavaScript, звідси десятки HTTP-запитів на рівному місці. Інструменти об'єднання (merge/combine) склеюють розрізнені файли в один, а мініфікація прибирає пробіли й коментарі. На виході замість 15-20 запитів скриптів, 1-2. Swift Performance робить це в розділі Scripts & Styles Optimization; після ввімкнення обов'язково перевірте фронтенд, рідкісні плагіни можуть зламатися й потребуватимуть виключення з об'єднання.

Вимкнення невикористовуваних плагінів

Деактивуйте все, що не використовується просто зараз. Кожен активний плагін — це потенційний запит, фонове завдання крона або зайвий скрипт. Зайдіть у «Плагіни → Встановлені» та пройдіться списком: конструктор форм, який ви поставили для однієї сторінки рік тому? Вимкнути. Експериментальний SEO-плагін, що дублює основний? Видалити.

Оптимізація бази даних

З часом у базі накопичуються ревізії постів, прострочені transient-записи, спам-коментарі та мета-дублікати. Swift Performance у розділі Database прибирає це сміття однією кнопкою. Для регулярного очищення налаштуйте розклад, раз на тиждень достатньо.

Відкладене завантаження (lazy load)

YouTube-вставки та Google-карти завантажуються важко: один ролик може потягнути за собою сотні кілобайтів ще до того, як користувач до нього докрутив. Увімкніть lazy load для iframe, відео підвантажиться лише під час прокручування до нього. Для зображень lazy load дає скромніший приріст, але теж не завадить.

Медіа та шрифти: прибираємо жир

Оптимізація зображень

Зображення, зазвичай найважчий актив на сторінці. До завантаження на сайт зменшуйте їхній фізичний розмір: скриншот шириною 2400 px на сайті з контентною областю 800 px — це зайві кілобайти. Використовуйте Adobe Photoshop або безплатний GIMP для обрізання до потрібної ширини.

Після завантаження зображення проганяють через оптимізатор. Swift Performance (вкладка Media) стискає PNG і JPEG із контрольованою втратою якості, візуальної різниці немає, а розмір файлу зменшується в рази.

Шрифти: менше, швидше

Google Fonts типово завантажуються із зовнішнього сервера, зайвий DNS-запит і затримка. Рішення, хостити шрифти локально, завантаживши їх у папку теми. Swift Performance завантажує Google Fonts на ваш сервер автоматично (вкладка Fonts).

Обмежте кількість накреслень: одна гарнітура + два насичення (regular і bold) = 2 запити. Три гарнітури з чотирма насиченнями кожна = 12 запитів. Різниця у швидкості відчутна.

Font Awesome без гігантського файлу

Повний набір Font Awesome важить ~120 КБ, хоча реально сайт використовує 3-5 іконок. Функція Critical Font у Swift Performance збирає кастомний файл лише з тими іконками, які реально присутні в коді сторінки. Розмір падає з ~120 КБ до 5-10 КБ.

Favicon через Data URI

Маленька іконка сайту часто виявляється останнім елементом у ланцюжку завантаження і затримує подію «повне завантаження» на 200-400 мс. Рішення, вбудувати іконку напряму в HTML через кодування base64, прибравши зайвий HTTP-запит.

Кодуєте .ico-файл у base64 через Data URL Maker, вставляєте код у functions.php:

1
function add_favicon() {
2
    echo '<link rel="shortcut icon" type="image/x-icon"
3
    href="data:image/vnd.microsoft.icon;base64,AAABAAEAQEAAAAEAIAAo.......=" />';
4
}
5
add_action('wp_head', 'add_favicon');

Після цього видаліть оригінальний favicon із кастомайзера: Зовнішній вигляд → Налаштування → Ідентифікація сайту → Значок сайту → Видалити.

Не зловживайте картинками в темі

Легковагова тема, фундамент. WP Astra з інсталяційним розміром менше 50 КБ і відсутністю jQuery-залежності завантажується відчутно швидше за багатьох конкурентів. Перед вибором теми перевірте її через той самий GTmetrix на демо-сервері.

Фінальна зачистка: точкові налаштування

Вимкнення пінгбеків і трекбеків

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

Для майбутніх постів: Налаштування → Обговорення → зняти галочку «Дозволити посилання-сповіщення з інших блогів (пінгбеки та трекбеки) на нові статті».

Для наявних постів: Пости → Усі пости → вибрати всі → Масова дія: Змінити → Застосувати → Пінги → Не дозволяти → Оновити.

Вимкнення непотрібних функцій WordPress

Емодзі WordPress додають DNS-префетч і зайвий скрипт (wp-emoji-release.min.js) на кожну сторінку. Gravatar-запити тягнуть зовнішні виклики для аватарів коментаторів. І те й інше вимикається через Swift Performance (вкладка Tweaks) парою галочок. Економія: мінус 2-3 HTTP-запити і кілька десятків кілобайт.

Один сайт, один обліковий запис хостингу

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

Повторні HTTP-запити від конструкторів сторінок

Elementor та інші page builder'и можуть дублювати запити Google Fonts і Font Awesome, навіть якщо шрифти вже завантажені локально. Після налаштування локального хостингу шрифтів обов'язково перевірте Waterfall у GTmetrix: шукайте зайві виклики fonts.googleapis.com і fontawesome.com. Знайшлися, зайдіть у налаштування конструктора і вимкніть завантаження шрифтів/іконок на рівні плагіна.

⁉️🤔 Поширені запитання

Який хостинг обрати для швидкого WordPress?

A2 Hosting і SiteGround стабільно показують низький TTFB у тестах на європейських та американських серверах. Ключовий критерій, наявність дата-центру в регіоні вашої аудиторії. Для проєктів із бюджетом від $15/міс розгляньте керований WordPress-хостинг: провайдер сам стежить за кешуванням, версією PHP і серверною оптимізацією.

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

Серверний кеш (Varnish, Nginx FastCGI) і плагін кешування працюють на різних рівнях і не дублюють, а доповнюють одне одного. Серверний кеш швидший (взагалі немає запуску PHP), але не керує об’єднанням скриптів, лінивим завантаженням і очищенням бази. Плагін на кшталт Swift Performance закриває ці завдання, ставте обидва.

Наскільки реально завантажити WordPress за 0,5 секунди?

Реально, але лише для добре оптимізованої легкої сторінки на швидкому хостингу з кешуванням і CDN, під час тестування з географічно близького регіону. Пересічний сайт із комерційною темою, десятком плагінів і медіаконтентом вкладається в 1,5-2,5 секунди після оптимізації за всіма 21 пунктами — це чудовий результат, який не шкодить SEO та користувацькому досвіду.

Чи потрібно оновлювати PHP до останньої версії?

Так, але з оглядкою на сумісність. PHP 8.3 дає приріст близько 30% порівняно з 7.4 на чистому виконанні коду. Перед оновленням оновіть усі плагіни й тему до останніх версій і зробіть бекап. Якщо сайт на застарілому плагіні, який не оновлювався з 2022 року, спочатку замініть плагін аналогом, потім змінюйте PHP.

Що робити, якщо після всіх порад швидкість усе одно низька?

Поверніться до GTmetrix Waterfall і пройдіть ланцюжком згори донизу. Шукайте: (1) повільний TTFB, проблема в хостингу або відсутності кешу; (2) довге завантаження конкретних скриптів, імовірно, гальмує зовнішній ресурс, розгляньте локальний хостинг; (3) велику кількість запитів, бракує об’єднання скриптів/стилів; (4) важкі зображення, перевірте, чи всі стиснуті й чи не завантажуються в повній роздільній здатності. Зазвичай один із цих чотирьох пунктів усуває левову частку залишкового сповільнення.

Чи варта гра свічок: що дають ці 21 крок

Швидкість сайту — це не разова акція, а гігієна. З 21 прийому є три, які дають негайний ефект: кешувальний плагін (налаштування за 10 хвилин), стиснення GZIP (одна галочка) і CDN (базовий Cloudflare вмикається за пів години). Зробіть їх сьогодні, і завтра GTmetrix покаже принципово інші цифри.

Решта кроків добирають відсотки. Оптимізація зображень, локальні шрифти й очищення бази не змінять картину поодинці, але разом відкушують відчутні частки від часу завантаження, що залишився. Пройдіть список до кінця, і ваш сайт виявиться швидшим за більшість конкурентів на WordPress.