Прискорення WordPress: кеш, зображення та CDN

Повільний WordPress втрачає відвідувачів і позиції в Google. Швидкий сайт починається з NVMe-хостингу та правильного налаштування кешування.

1. Кешування сторінок

Встановіть плагін кешування — це найважливіше покращення:

• WP Rocket — найкращий (платний, $59/рік). Включає все з коробки
• LiteSpeed Cache — безкоштовний, ідеально на LiteSpeed-серверах
• W3 Total Cache — безкоштовний, гнучке налаштування

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

# Конвертація в WebP через плагін:
# ShortPixel, Imagify, або WebP Express

# Або через командний рядок:
sudo apt install webp
cwebp -q 85 image.jpg -o image.webp

Додатково:

• Встановіть плагін Smush або ShortPixel для стиснення без втрати якості
• Додайте атрибут loading="lazy" — WP 5.5+ робить це автоматично
• Використовуйте правильні розміри: не завантажуйте 4000px для мініатюри 300px

3. Мініфікація CSS та JS

У WP Rocket: увімкніть Minify CSS files та Minify JavaScript files.

Безкоштовна альтернатива — плагін Autoptimize.

4. Cloudflare CDN (безкоштовно)

1. Зареєструйтеся на cloudflare.com
2. Додайте домен → Cloudflare видасть NS-сервери
3. Замініть NS у налаштуваннях домену в реєстратора
4. Увімкніть Caching → Caching Level: Standard

5. PHP 8.2 замість 7.4

У cPanel → Версії PHP перемкніть на PHP 8.2. Приріст продуктивності — до 30%.

Результати оптимізації

Часті помилки під час пришвидшення WordPress

Агресивна оптимізація без розуміння причини частіше ламає сайт, ніж пришвидшує його. Розберемо типові помилки.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wp-image-editor-imagick.php on line 226

Ця помилка з'являється під час масової регенерації мініатюр або конвертації у WebP через wp media regenerate чи плагін ShortPixel: PHP не вкладається в ліміт memory_limit (зазвичай 256 МБ на хостингу), обробляючи великі оригінали. Рішення — підняти ліміт у php.ini до 512M на час конвертації або обробляти зображення партіями по 50–100 файлів.

Invalid command 'AddOutputFilterByType', perhaps misspelled or defined by a module not included in the server configuration

Такий запис у логах Apache означає, що модуль mod_deflate не підключений на сервері, а правило в .htaccess вже додано. Без <IfModule mod_deflate.c> сайт впаде з 500-ю помилкою одразу після збереження файлу — обгортайте директиви стиснення перевіркою модуля, як у прикладі вище.

Порівняння кешувальних плагінів

LiteSpeed Cache дає максимум лише на серверах із веб-сервером LiteSpeed — на Apache чи Nginx частина функцій (наприклад, ESI) недоступна, і різниця з W3 Total Cache зникає.

Коли пришвидшення не дасть ефекту

Кеш сторінок не рятує інтернет-магазин на WooCommerce: сторінки кошика, оформлення замовлення та особистого кабінету завжди динамічні й не кешуються повністю — для них потрібен об'єктний кеш на кшталт Redis для WordPress, а не лише плагін кешування сторінок. Якщо TTFB вищий за 600 мс уже на порожній сторінці без плагінів — проблема не у WordPress, а в перевантаженому тарифі хостингу чи повільному диску; кеш пришвидшить повторні візити, але не вирішить першопричину. Плагіни-конструктори сторінок (Elementor, Divi) додають власний CSS/JS на кожен запит — мініфікація зменшить розмір файлів, але не кількість запитів до сервера.

Як перевірити результат

Самого PageSpeed Insights недостатньо — він показує Lab Data (один прогін) і Field Data (реальні візити за 28 днів), які можуть розходитися. Перевіряйте обидва показники і TTFB безпосередньо:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/
curl -I https://example.com/ | grep -i "cache\|content-encoding"

У заголовках шукайте Content-Encoding: gzip або br і ознаки кешу (X-Cache: HIT, cf-cache-status: HIT). Якщо після увімкнення плагіна заголовки не змінилися — кеш не активувався, перевірте конфлікт з іншим плагіном кешування або налаштуваннями Cloudflare.

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