Повільний сайт — це не просто незручність. Кожна зайва секунда завантаження збільшує відсоток відмов, знижує конверсію і погіршує позиції в Google. Але є і хороша новина: WordPress чудово піддається оптимізації, і більшість покращень можна зробити без глибоких технічних знань.
У цьому гіді ми пройдемо весь шлях — від розуміння того, що саме уповільнює сайт, до конкретних налаштувань, які реально дають результат. Матеріал розрахований на власників сайтів, адміністраторів і розробників середнього рівня.
1. Чому WordPress-сайти гальмують
Перш ніж щось оптимізувати, варто зрозуміти причини. WordPress є гнучкою системою, і саме ця гнучкість нерідко стає джерелом проблем з продуктивністю.
Занадто багато плагінів. Кожен плагін — це додатковий PHP-код, SQL-запити і, часто, зайві CSS/JS-файли на всіх сторінках без винятку. П’ять погано написаних плагінів можуть уповільнити сайт більше, ніж двадцять якісних.
Важкі зображення. Нестиснуті JPEG і PNG-файли по 2–5 МБ — одна з найпоширеніших причин повільного завантаження. Браузер не може показати сторінку, поки не завантажить весь «важкий» контент у верхній частині.
Відсутність кешування. Без кешу WordPress при кожному запиті виконує PHP-скрипти і робить десятки запитів до бази даних — навіть якщо сторінка взагалі не змінювалась.
Неоптимізована база даних. З часом WordPress накопичує «сміття»: тисячі ревізій записів, прострочені транзієнти, сліди видалених плагінів. Це уповільнює SQL-запити.
Блокуючі скрипти. JavaScript, який завантажується у <head> без атрибута defer, блокує відображення сторінки — браузер чекає, доки скрипт не завантажиться і не виконається.
2. Спочатку вимірюємо — потім оптимізуємо
Оптимізація навмання — це витрата часу. Щоб зрозуміти, де саме проблема, потрібні конкретні дані. Google запровадив набір метрик Core Web Vitals, які безпосередньо впливають на ранжування сайту.
| Метрика | Ціль | Тривожна зона |
| LCP — завантаження головного контенту | < 2.5 с | > 4.0 с |
| INP — реакція на взаємодію | < 200 мс | > 500 мс |
| CLS — стабільність макету | < 0.1 | > 0.25 |
| TTFB — час до першого байта | < 800 мс | > 1800 мс |
Інструменти для аналізу:
Google PageSpeed Insights — головний інструмент. Показує реальні дані з браузерів користувачів (поле) і лабораторні результати (Lighthouse). Аналізуйте окремо мобільну та десктопну версії — різниця буває разючою.
GTmetrix — детальний каскад завантаження (Waterfall). Дозволяє побачити, які саме ресурси завантажуються довго і що блокує рендеринг.
WebPageTest — найгнучкіший варіант для поглибленого тестування: вибір локації, емуляція 3G/4G, відеозапис процесу завантаження.
Query Monitor — плагін для WordPress, який показує всі SQL-запити, їх час виконання і стек викликів прямо в адмінці.
3. Хостинг: від чого залежить швидкість на рівні сервера
Хостинг — важливий фактор, але не завжди вирішальний. Якісний вітртуальний хостинг без агресивного ovreselling цілком підходить для більшості WordPress-сайтів: блогів, корпоративних сторінок, невеликих магазинів. Проблеми виникають передусім через провайдерів, які розміщують надто багато сайтів на одному сервері.
На що звертати увагу при виборі тарифу: наявність SSD-дисків (не HDD), підтримка актуальної версії PHP (8.1+), увімкнений OPcache, виділена пам’ять для процесів PHP. Ці параметри важливіші за формальний тип хостингу.
Коли справді варто переходити на VPS
Переїзд на VPS або виділений сервер має сенс, коли сайт дійсно переріс shared-середовище: великий інтернет-магазин з десятками тисяч товарів, портал з активним контентом від користувачів, або сайт з великим піковим навантаженням одночасних відвідувачів. В інших випадках — спочатку оптимізуйте, потім думайте про апгрейд.
PHP: найпростіше прискорення
Версія PHP безпосередньо впливає на швидкість виконання коду. PHP 8.1+ в середньому на 25–40% швидший за PHP 7.4 завдяки JIT-компіляції. Перевірити поточну версію можна в панелі керування хостингом — і перемкнути її там само, без будь-яких змін на сайті.
4. Кешування: сайт, який не думає двічі
Кешування — найефективніша оптимізація WordPress. Ідея проста: замість того щоб щоразу виконувати PHP і робити запити до бази даних, зберігаємо готовий результат і віддаємо його наступним відвідувачам напряму.
Кешування сторінок (Page Cache)
Page Cache зберігає готовий HTML кожної сторінки на диску або в пам’яті. Перший відвідувач генерує сторінку звично (PHP + MySQL), всі наступні отримують готовий файл. TTFB падає з 300–600 мс до 20–50 мс — без змін у коді.
Налаштовується через кешуючий плагін.
Object Cache: APCu, Redis або Memcached
WordPress має вбудований object cache, але він живе тільки в межах одного запиту — при наступному запиті все обнуляється. Persistent object cache зберігає об’єкти між запитами і суттєво знижує кількість звернень до бази даних.
- APCu — PHP-розширення для кешування в пам’яті процесу. Це розширення доступне на більшості shared-хостингів там, де Redis і Memcached відсутні. Плагін W3 Total Cache підтримує APCu нативно — це зручний вибір для shared-середовища.
- Redis — найфункціональніший варіант: підтримує складні структури даних, персистентність і реплікацію. Доступний на VPS або виділених серверах.
- Memcached — простіша альтернатива. Добре справляється з кешуванням об’єктів, але без розширених функцій Redis. Так як і Redis може боти встановлений на VPS або виділених серверах
Browser Cache: нехай браузер пам’ятає
Налаштуйте HTTP-заголовки Cache-Control для статичних ресурсів — і браузер зберігатиме їх локально. При повторному відвідуванні сторінка завантажиться значно швидше, бо CSS, зображення і шрифти вже є на пристрої.
Рекомендовані TTL: зображення, шрифти, CSS/JS з хешованими іменами — 1 рік. HTML-сторінки — 0 або не більше кількох годин. Налаштовується через .htaccess (Apache), конфіг nginx або кешуючий плагін.
Для активації Browser Cache без використання плагінів достатньо додати наступні правила в файл .htaccess:
ExpiresActive On
# Images
ExpiresByType image/jpeg “access plus 1 year”
ExpiresByType image/gif “access plus 1 year”
ExpiresByType image/png “access plus 1 year”
ExpiresByType image/webp “access plus 1 year”
ExpiresByType image/svg+xml “access plus 1 year”
ExpiresByType image/x-icon “access plus 1 year”
# Video
ExpiresByType video/webm “access plus 1 year”
ExpiresByType video/mp4 “access plus 1 year”
ExpiresByType video/mpeg “access plus 1 year”
# Fonts
ExpiresByType font/ttf “access plus 1 year”
ExpiresByType font/otf “access plus 1 year”
ExpiresByType font/woff “access plus 1 year”
ExpiresByType font/woff2 “access plus 1 year”
ExpiresByType application/font-woff “access plus 1 year”
ExpiresByType application/font-woff2 “access plus 1 year”
# CSS, JavaScript
ExpiresByType text/css “access plus 1 year”
ExpiresByType text/javascript “access plus 1 year”
ExpiresByType application/javascript “access plus 1 year”
# Others
ExpiresByType application/pdf “access plus 1 year”
ExpiresByType image/vnd.microsoft.icon “access plus 1 year”
</IfModule>
5. GZIP: стискаємо все
Стиснення на рівні передачі — один із найпростіших способів зменшити розмір сторінки без жодних змін у коді чи контенті. Сервер стискає файл перед відправкою, браузер розпаковує його за мілісекунди. Для відвідувача все прозоро, а сторінка важить втричі менше.
GZIP — перевірений стандарт, підтримується абсолютно всіма браузерами і серверами. Якщо ви ще не увімкнули нічого — починайте з нього.
Brotli — сучасний алгоритм від Google, який стискає на 15–25% ефективніше за GZIP при тій самій якості. Підтримується всіма актуальними браузерами (Chrome, Firefox, Safari, Edge) і сучасними серверами (nginx 1.11.6+, Apache з модулем mod_brotli). Якщо ваш хостинг підтримує Brotli — використовуйте його. Якщо ні — GZIP вже дає чудовий результат.
Як увімкнути:
На більшості хостингів GZIP вже увімкнено за замовчуванням. Якщо ні, ось як це виправити:
• Apache (.htaccess): додайте директиви mod_deflate або mod_gzip. Достатньо просто додати наступний код:
<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>
6. Зображення: найбільший резерв швидкості
Зображення становлять 50–70% ваги середньої веб-сторінки. При цьому їх оптимізація — одна з найпростіших задач: не потрібно змінювати код, достатньо правильно налаштувати один плагін.
Сучасні формати: WebP і AVIF
WebP дає на 25–35% менший розмір файлу порівняно з JPEG при тій самій візуальній якості. Підтримується всіма сучасними браузерами. Плагін автоматично конвертує наявні зображення та роздає WebP тим браузерам, які його розуміють.
AVIF — ще ефективніший формат (до 50% краще за JPEG), але підтримка браузерів поки неповна. Використовуйте як доповнення до WebP через тег <picture> з fallback.
Lazy Loading — завантажуємо тільки те, що видно
Відкладене завантаження означає, що браузер завантажує лише зображення у видимій частині екрана. Все інше — в міру прокрутки. WordPress 5.5+ додає атрибут loading=”lazy” автоматично.
Але є нюанс: перше зображення на сторінці (яке входить в LCP) не повинно мати lazy loading. Навпаки — воно має завантажуватись з пріоритетом. Додайте йому атрибут fetchpriority=”high” або використайте WordPress-функцію з параметром ‘loading’ => ‘eager’.
Правильні розміри і srcset
Не завантажуйте зображення 2000px там, де відображається мініатюра 300px. WordPress автоматично генерує кілька розмірів і використовує атрибут srcset — але тільки якщо зображення вставлено через вбудований медіабраузер або функцію wp_get_attachment_image(). При прямому зверненні через URL ця магія не працює.
7. База даних: підтримуємо порядок
WordPress зберігає в базі даних все: записи, налаштування, кешовані значення, логи плагінів. З часом база «пухне» — і запити сповільнюються. Регулярне обслуговування займає 10 хвилин і помітно впливає на TTFB.
Що прибирати і як часто
- Ревізії записів: WordPress зберігає кожну версію кожного запису. Обмежте їх кількість у wp-config.php:
define(‘WP_POST_REVISIONS’, 5);
і видаліть накопичені. WP-CLI команда:
wp post delete $(wp post list –post_type=’revision’ –format=ids). - Прострочені транзієнти:
wp transient delete –expired
Деякі плагіни залишають тисячі рядків у wp_options — це уповільнює всі запити до цієї таблиці. - Spam і видалені коментарі:
wp comment delete $(wp comment list –status=spam –format=ids). - Оптимізація таблиць: OPTIMIZE TABLE в phpMyAdmin або wp db optimize. Раз на місяць достатньо.
Slow Query: знаходимо вузькі місця
Query Monitor у WordPress показує які запити виконуються повільно в реальному часі для поточної сторінки. Більше 50 запитів на сторінку — привід розібратися. Більше 100 — серйозна проблема.
8. CDN: сайт, який близько до кожного
CDN (Content Delivery Network) — мережа серверів, розподілена географічно. Статичні ресурси (зображення, CSS, JS, шрифти) роздаються з найближчого до відвідувача вузла. Замість того щоб файл летів з Польщі до Австралії — він вже є в Сіднеї.
Підключення CDN дає два результати одночасно: менша затримка для географічно віддалених відвідувачів і зниження навантаження на основний сервер. Для сайтів з міжнародною аудиторією це критично важливо.
HTTP/2 і HTTP/3: сучасні протоколи
HTTP/2 підтримує мультиплексування — кілька запитів через одне з’єднання одночасно. Це усуває проблему черги запитів, актуальну для HTTP/1.1. Переконайтесь, що ваш сервер підтримує HTTP/2 — у сучасних nginx і Apache це стандартна функція.
HTTP/3 (на базі QUIC) іде ще далі: усуває затримку head-of-line blocking на рівні транспорту і краще працює в умовах поганого з’єднання. Підтримується сучасними версіями nginx і більшістю CDN-сервісів.
9. Які плагіни дійсно допомагають
Ось перевірений набір інструментів, кожен з яких вирішує конкретну задачу:
| Плагін | Категорія | Безкоштовний | Примітка |
| W3 Total Cache | Кешування | Так | Підтримує APCu, Redis, Memcached |
| LiteSpeed Cache | Кешування | Так | Найкращий вибір для LiteSpeed-серверів |
| Smush | Оптимізація зображень | Так | Автоматична компресія та WebP |
| Imagify | Оптимізація зображень | Частково | Підтримує WebP та AVIF |
| Asset CleanUp | Керування скриптами | Так | Вимикає зайві CSS/JS по URL |
| Query Monitor | Діагностика | Tak | Аналіз SQL-запитів і хуків |
| Autoptimize | Мінімізація CSS/JS | Так | Конкатенація та defer скриптів |
| Disable Emojis | Прибирання зайвого | Так | Видаляє emoji-скрипт WordPress |
Підсумок
Прискорення WordPress — це послідовна робота і потребує уваги і часу. Починайте з вимірювання: PageSpeed Insights покаже, де саме проблема. Потім ідіть за пріоритетами: кешування і OPcache дадуть чималий ефект при мінімальних зусиллях, зображення — другий за значимістю резерв, фронтенд і база даних — на завершення.
Більшість сайтів можна довести до оцінки 85–95 в PageSpeed без жодних змін у коді — тільки правильними налаштуваннями.