Оптимізація продуктивності WordPress: кеш, БД, Core Web Vitals

Проблема: дефолтний WordPress — повільний та ненажерливий

WordPress з дефолтними налаштуваннями повільний: кожен запит до сторінки виконує 60–120 SQL-запитів, завантажує десятки плагінів і генерує HTML заново. Типовий сайт на WordPress видає TTFB 1–3 секунди, LCP перевищує 4 секунди — відвідувачі йдуть, не дочекавшись завантаження. Ми щодня стикаємося з такими проектами і знаємо, як це виправити. Оптимізація продуктивності WordPress з кешуванням (OPcache, Redis, Nginx-кеш) та очищенням БД дає значний приріст швидкості. Наша команда має 5+ років досвіду в цій сфері. Зв'яжіться з нами для проведення аудиту продуктивності — пишіть нам, ми оцінимо ваш проект безкоштовно.

Наша методика оптимізації продуктивності WordPress включає комплекс заходів: від налаштування OPcache і Redis до конвертації зображень у WebP та оптимізації SQL-запитів. За роки роботи (з 2019) ми провели понад 50 аудитів і гарантуємо зниження TTFB до 200 мс і Core Web Vitals у зеленій зоні. Як показує практика, навіть базова оптимізація окупається за 2–3 місяці за рахунок скорочення навантаження на хостинг.

Згідно з дослідженням Pingdom, кожні зайві 100 мс TTFB знижують конверсію на 1%.

Аудит продуктивності WordPress: що гальмує ваш сайт

Перед оптимізацією — діагностика. Інструменти:

• Query Monitor — показує всі SQL-запити та хуки на кожній сторінці
• New Relic або Tideways — профілювальник PHP для production
• GTmetrix / PageSpeed Insights — зовнішні метрики Core Web Vitals

Типові причини повільної роботи:

• Відсутність PHP OPcache
• Немає object cache (Redis/Memcached)
• Повільні плагіни з неоптимальними WP_Query
• Таблиця wp_options з тисячами autoload-опцій (деякі розміром >1 МБ)
• Величезна таблиця wp_postmeta (сотні тисяч записів)
• Відсутність кешування сторінок

Як OPcache і Redis зменшують кількість SQL-запитів?

Налаштування OPcache

# /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.fast_shutdown=1
opcache.jit=tracing
opcache.jit_buffer_size=64m

Згідно з документацією PHP, ці налаштування дають 30–50% зниження часу виконання PHP.

Redis для object cache

Встановіть Redis через apt, активуйте плагін Redis Cache. Пропишіть у wp-config.php:

define('WP_CACHE_KEY_SALT', 'yourdomain.com_');
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Redis кешує результати WP_Query, опції (get_option), дані користувачів. На одному проекті з 2000 постами і 50 плагінами Redis знизив кількість SQL-запитів на сторінку з 90 до 12. Redis object cache в 5-10 разів ефективніший за стандартний transient API.

Чому Nginx FastCGI Cache кращий за плагіни кешування?

Для високонавантажених сайтів використовуємо Nginx FastCGI Cache — він минає PHP і WordPress повністю.

fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 301 302 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;

        set $skip_cache 0;
        if ($http_cookie ~* "wordpress_logged_in|woocommerce_cart_hash") {
            set $skip_cache 1;
        }
        if ($request_method = POST) { set $skip_cache 1; }

        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    }
}

Порівняння Nginx та плагінів:

Кешовані сторінки віддаються з TTFB < 10 мс. Nginx FastCGI Cache в 10–20 разів швидший за плагіни.

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

Очищення БД

-- Удаление старых ревизий (оставить последние 5 на пост)
DELETE p FROM wp_posts p
LEFT JOIN (
    SELECT ID FROM wp_posts
    WHERE post_type = 'revision'
    ORDER BY post_date DESC
    LIMIT 5
) keep ON p.ID = keep.ID
WHERE p.post_type = 'revision' AND keep.ID IS NULL;

-- Удаление орфанных postmeta
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

-- Анализ autoload options
SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

-- Отключить autoload для ненужных опций
UPDATE wp_options SET autoload = 'no'
WHERE option_name IN ('_transient_some_plugin_cache', 'some_large_option');

WebP-конвертація

Підключаємо автоматичну конвертацію при завантаженні медіафайлів через плагін ShortPixel або свій обробник на Imagick. Це дозволяє без ручної роботи перевести весь контент у сучасний формат, заощаджуючи до 30% трафіку.

Які ще техніки прискорення ми застосовуємо?

Додатково налаштовуємо lazy loading для зображень, мініфікацію CSS/JS (через Autoptimize або збірку на Webpack), підключаємо CDN (Cloudflare) і використовуємо WebP-файли з srcset. Комплексний підхід дає максимальний приріст швидкості.

Покроковий план оптимізації

1. Аудит: профілювання з Query Monitor і New Relic.
2. OPcache: увімкнути та налаштувати JIT.
3. Redis: встановити, налаштувати object cache.
4. Nginx-кеш: налаштувати FastCGI Cache з обходом для авторизованих.
5. БД: очистити ревізії, orphaned meta, відключити autoload для великих опцій.
6. Зображення: конвертувати в WebP, налаштувати lazy loading.
7. Моніторинг: перевірка Core Web Vitals через PageSpeed Insights.
8. Фінальний звіт та рекомендації під ключ.

Що входить у роботу та які результати?

• Детальний аудит продуктивності зі звітом
• Налаштування OPcache та Redis
• Конфігурація Nginx FastCGI Cache (або іншого кешу)
• Очищення та оптимізація бази даних
• Мініфікація CSS/JS, конвертація зображень у WebP
• Рекомендації щодо покращення LCP, CLS, INP
• Гарантія: TTFB < 200 мс та Core Web Vitals у зеленій зоні
• Документація та навчання команди

Вартість: від 200$ за базову оптимізацію, повний аудит — від 500$. Терміни: базова оптимізація — 2–3 дні, повний аудит — 5–7 днів.

Типові результати:

Терміни та досвід

Ми працюємо з WordPress з 2019 року і реалізували понад 50 успішних проектів. Надішліть нам посилання на ваш сайт — проведемо безкоштовний глибокий аналіз. Маєте питання? Напишіть нам — ми оцінимо ваш проект і запропонуємо оптимальний план оптимізації під ключ.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.