Как выполняется аудит производительности WordPress?
Клиент запустил интернет-магазин на WordPress с темой Avada и 50+ плагинами. Google PageSpeed показывает TTFB 1.2 секунды, а LCP — 6 секунд. Пользователи жалуются на долгую загрузку, конверсия упала на 20%. Мы провели аудит производительности WordPress и выявили: автозагрузка wp_options перегружена (3 MB данных), MySQL без индексов на таблице postmeta, OPcache отключён. Исправили за 2 дня — время загрузки упало до 1.5 секунд, конверсия восстановилась. Только измерение даёт правильный вектор для оптимизации.
Аудит производительности WordPress — это комплексная диагностика серверной и клиентской частей. Мы проверяем конфигурацию PHP (OPcache, memory limit), MySQL (индексы, slow queries), кэширование (page cache, object cache), фронтенд (CSS/JS бандлы, изображения) и конфигурацию веб-сервера (HTTP/2, brotli). Без такого аудита оптимизация наугад может усугубить ситуацию, добавив новые проблемы. На основе результатов мы составляем план с приоритетами и точными инструкциями.
Почему без аудита оптимизация неэффективна?
Многие пытаются ускорить сайт наугад: включают плагины, сжимают изображения, меняют хостинг. Без точных данных это стрельба вслепую. Аудит показывает, что именно тормозит: сервер, база данных, плагины или фронтенд. Мы начинали с проекта, который грузился 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 раз эффективнее файлового кэша.
Как измеряем метрики?
Измерить базовые метрики до оптимизации:
# 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 мс.
Типичные проблемы и их влияние
| Проблема | Влияние | Исправление |
|---|---|---|
| Нет OPcache | -40% PHP time | Включить в php.ini |
| Нет Redis/Memcached | -50-70% DB queries | Установить object cache |
| Нет кэша страниц | TTFB 500ms+ | WP Rocket / FastCGI cache |
| Неоптимизированные изображения | +2-5 MB на страницу | WebP + ресайз |
| Render-blocking JS | LCP +1-3 с | defer/async |
| Autoload options > 1 MB | +200ms на каждый запрос | Очистка wp_options |
| Медленный плагин | +300ms | Замена или оптимизация |
| Нет CDN | +500ms для удалённых пользователей | Cloudflare / BunnyCDN |
| HTTP/1.1 вместо HTTP/2 | Множественные RTT | Включить в Nginx |
| Нет gzip/brotli | +200-500 KB трафика | Включить в Nginx |
Core Web Vitals: целевые значения
Согласно Google Search Central, эти метрики являются ключевыми для ранжирования. LCP (Largest Contentful Paint) должен быть менее 2.5 секунд. LCP — критический показатель скорости загрузки.
| Метрика | Хорошо | Нужна работа | Плохо |
|---|---|---|---|
| LCP | < 2.5 с | 2.5–4 с | > 4 с |
| INP | < 200 мс | 200–500 мс | > 500 мс |
| CLS | < 0.1 | 0.1–0.25 | > 0.25 |
| TTFB | < 200 мс | 200–800 мс | > 800 мс |
Пошаговый план аудита
- Сбор метрик с помощью Lighthouse CLI, PageSpeed Insights и WebPageTest.
- Анализ серверной части через Query Monitor, slow logs и профилировщик PHP.
- Выявление узких мест: медленные запросы, конфигурация кэша, тяжёлые плагины.
- Составление отчёта с приоритетами и конкретными инструкциями по каждой проблеме.
- Тестирование исправлений и повторный замер для подтверждения улучшений.
Что входит в отчёт
- Измеренные метрики до оптимизации
- Перечень проблем с приоритетами (критичные, важные, улучшения)
- Конкретные рекомендации по каждой проблеме (с кодом или настройками)
- Прогнозируемый результат после исправления (ожидаемое снижение времени загрузки)
- Документация по результатам, доступы (если требуется), рекомендации по поддержке
Типичные ошибки при самостоятельной оптимизации
- Установка слишком многих плагинов кэширования, которые конфликтуют.
- Использование изображений без WebP и без responsive sizes.
- Игнорирование slow query log и отсутствие индексов в БД.
- Отключение OPcache при высокой нагрузке.
- Выбор хостинга по цене, а не по ресурсам.
Сроки и стоимость
Аудит производительности WordPress-сайта с подготовкой отчёта и рекомендаций занимает 1–2 дня. Стоимость рассчитывается индивидуально в зависимости от сложности и объёма. После оптимизации заказчики экономят до 30% на хостинге и поддержке. Получите консультацию или закажите аудит — мы поможем улучшить производительность вашего сайта.