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

Проблема: дефолтный WordPress — медленный и голодный

WordPress с дефолтными настройками медленный: каждый запрос к странице выполняет 60–120 SQL-запросов, загружает десятки плагинов и генерирует HTML заново. Типичный сайт на WordPress выдаёт TTFB 1–3 секунды, LCP превышает 4 секунды — посетители уходят, не дождавшись загрузки. Мы ежедневно сталкиваемся с такими проектами и знаем, как это исправить. Оптимизация производительности WordPress — это не разовая акция, а системный подход, который даёт измеримые результаты. Свяжитесь с нами для проведения аудита производительности.

Наша методика включает комплекс мер: от настройки OPcache и Redis до конвертации изображений в WebP и оптимизации SQL-запросов. За годы работы мы провели более 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.

Почему 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.

Что входит в работу и какие результаты?

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

Типичные результаты:

Сроки и опыт

Базовая оптимизация (OPcache, Redis, очистка БД, кэш страниц) — 2–3 дня. Полный аудит с профилировкой и оптимизацией медленных запросов — 5–7 дней. Стоимость рассчитывается индивидуально в зависимости от сложности.

Многолетний опыт и 50+ успешных проектов подтверждают эффективность нашего подхода. Закажите аудит сегодня и получите гарантированный результат.

Почему Core Web Vitals критичны для технического SEO

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

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