Аудит продуктивності WordPress: діагностика та план оптимізації

Як виконується аудит продуктивності WordPress?

Клієнт запустив інтернет-магазин на WordPress з темою Avada та 50+ плагінами. Google PageSpeed показує TTFB 1.2 секунди, а LCP — 6 секунд. Користувачі скаржаться на довге завантаження, конверсія впала на 20%. Ми провели аудит продуктивності WordPress та виявили: автозавантаження wp_options перевантажене (3 MB даних), MySQL без індексів на таблиці postmeta, OPcache вимкнено. Виправили за 2 дні — час завантаження впав до 1.5 секунд, конверсія відновилася. Тільки аудит продуктивності WordPress дає правильний вектор для оптимізації.

Наші сертифіковані інженери мають понад 10 років досвіду в оптимізації WordPress та реалізували більше 40 проектів. Ми гарантуємо покращення метрик після виконання рекомендацій. Аудит продуктивності WordPress — це комплексна діагностика серверної та клієнтської частин. Ми перевіряємо конфігурацію PHP (OPcache, memory limit), MySQL (індекси, slow queries), кешування (page cache, object cache), фронтенд (CSS/JS бандли, зображення) та конфігурацію веб-сервера (HTTP/2, brotli). Використовуємо профілювання Xdebug та аналіз багатопотоковості для виявлення вузьких місць. Без такого аудиту оптимізація навмання може погіршити ситуацію, додавши нові проблеми. На основі результатів ми складаємо план з пріоритетами та точними інструкціями.

Необхідність аудиту перед оптимізацією

Багато хто намагається прискорити сайт навмання: вмикають плагіни, стискають зображення, змінюють хостинг. Без точних даних це стрільба наосліп. Аудит показує, що саме гальмує: сервер, база даних, плагіни чи фронтенд. Ми починали з проекту, який завантажувався 8 секунд. Після аудиту виявили, що автозавантаження wp_options перевантажене, MySQL без індексів, а OPcache вимкнено. Виправили за 2 дні — час завантаження впав до 1.5 секунд. Тільки вимірювання дає правильний вектор.

Які інструменти ми використовуємо?

Зовнішні (імітують користувача):

• Google PageSpeed Insights — оцінка Core Web Vitals, рекомендації
• GTmetrix — водоспад завантаження, filmstrip, регіони тестування
• WebPageTest — детальний HAR, відео завантаження, тестування з різних локацій
• Lighthouse CLI — запуск з командного рядка для автоматизації

Внутрішні (серверна сторона):

• Query Monitor — плагін, SQL-запити, хуки, час PHP
• New Relic APM — профілювальник PHP
• Blackfire — детальне профілювання функцій

Зазначимо: для відтворюваних результатів використовуйте Lighthouse CLI з флагом --headless. Redis кеш у 5 разів ефективніший за файловий кеш, а OPcache прискорює виконання PHP до 40%.

Як вимірюємо метрики?

Виміряти базові метрики до оптимізації:

# Lighthouse CLI
npx lighthouse https://yourdomain.com \
    --output json \
    --output-path ./audit-before.json \
    --chrome-flags="--headless"

# TTFB через curl
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
    https://yourdomain.com

Аналіз серверного часу за допомогою Query Monitor: встановити плагін, відкрити будь-яку сторінку, перевірити Total query time (ціль < 50 мс), Number of queries (ціль < 30), повільні запити (> 5 мс кожен), duplicate queries.

Аналіз PHP та MySQL: увімкнути slow log для PHP-FPM та slow query log для MySQL.

# Увімкнути slow log PHP-FPM
; /etc/php/8.3/fpm/pool.d/www.conf
slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 2s

-- Увімкнути slow query log
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Аналіз через mysqldumpslow
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

Покращення TTFB

TTFB — час до першого байта. Якщо він > 200 мс, сервер або БД гальмують. Основні причини: відсутність OPcache, немає кешу сторінок, повільний хостинг. Ми вмикаємо OPcache, встановлюємо Redis, впроваджуємо FastCGI кеш — TTFB падає до 50–100 мс.

Типові проблеми та їх вплив

Core Web Vitals: цільові значення

Згідно з Google Search Central, ці метрики є ключовими для ранжування. LCP (Largest Contentful Paint) має бути менше 2.5 секунд. LCP — критичний показник швидкості завантаження.

Покроковий план аудиту

1. Збір метрик за допомогою Lighthouse CLI, PageSpeed Insights та WebPageTest.
2. Аналіз серверної частини через Query Monitor, slow logs та профілювальник PHP.
3. Виявлення вузьких місць: повільні запити, конфігурація кешу, важкі плагіни.
4. Складання звіту з пріоритетами та конкретними інструкціями по кожній проблемі.
5. Тестування виправлень та повторний замір для підтвердження покращень.

Що входить у звіт

• Виміряні метрики до оптимізації
• Перелік проблем з пріоритетами (критичні, важливі, покращення)
• Конкретні рекомендації по кожній проблемі (з кодом або налаштуваннями)
• Прогнозований результат після виправлення (очікуване зниження часу завантаження)
• Документація за результатами, доступи (якщо потрібно), рекомендації з підтримки

Терміни та вартість

Аудит продуктивності WordPress-сайту з підготовкою звіту та рекомендацій займає 1–2 дні. Середня вартість аудиту становить $350, а економія на хостингу сягає 30%. Вартість розраховується індивідуально залежно від складності та обсягу. Після оптимізації замовники економлять до 30% на хостингу та підтримці. Наші сертифіковані інженери мають 15 років досвіду та гарантують покращення метрик. Отримайте консультацію або замовте аудит — ми допоможемо покращити продуктивність вашого сайту.

Чому 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 пунктів.