Если WordPress работает медленно, не начинайте с установки ещё одного плагина оптимизации. Предположим, что очевидные вещи уже проверены: изображения не весят по 5–10 МБ, базовое кеширование включено, а на странице нет гигантского видео или другого статического файла. Если сайт одновременно открывается с ошибками или не загружается, сначала полезно пройти диагностику неработающего сайта WordPress.
Если сайт после этого всё равно медленный, нужно искать конкретное место, где теряется время. Практическая последовательность:
измерить
↓
отделить backend от frontend
↓
проверить сервер → PHP → БД
↓
найти плагин / запрос → тему → cron
↓
проверить кеш и Cloudflare
↓
проверить frontend
↓
измерить сноваПосле каждого изменения должен быть повторный замер. Иначе невозможно понять, действительно ли сайт стал быстрее.
Сначала измерьте реальную скорость сайта
Не начинайте с ощущения «WordPress какой-то тормозной». Нужна цифра. В Chrome DevTools откройте Network, включите Disable cache и перезагрузите страницу. Сначала смотрите запрос основного HTML-документа.
F12
→ Network
→ Disable cache
→ перезагрузить страницуДля независимого замера используйте TTFB через curl:
curl -o /dev/null -s \
-w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
https://example.ru/Проведите несколько одинаковых замеров: один запрос может попасть в кеш, выполняться на холодном PHP-процессе или совпасть с фоновой нагрузкой.
↑ К оглавлениюПоймите, тормозит backend или frontend
Если Document ждёт ответа сервера 3.2 секунды, сначала проверяйте сервер, PHP, WordPress, базу, плагины, тему и внешние API. Если HTML приходит за 220 ms, но полная загрузка занимает 6.5 секунды, проверяйте JavaScript, CSS, шрифты, виджеты, сторонние скрипты и DOM.
Сравните несколько URL: если главная и статьи быстрые, а checkout занимает 4.9 секунды, проблема локализована вокруг checkout. Если медленный весь сайт и /wp-admin/, подозревайте общую часть bootstrap, PHP, БД или глобальный плагин.
TTFB: 3.820s
Total: 3.910sПроверьте сервер: CPU, RAM и диск
На VPS проверьте free -h и значения available и swap, затем df -h для разделов WordPress, MySQL/MariaDB и логов. Нагрузку покажут uptime, top или htop. Важно понять, кто потребляет CPU: php-fpm, mysqld, nginx или другой процесс.
Сравните статический файл, например /style.css, с /. Если статика отдаётся за 35 ms, а WordPress за 3400 ms, сеть, TLS и web server, вероятно, работают, а проблема начинается в PHP, WordPress или БД. Если медленный даже статический файл, CMS пока лучше не трогать.
Проверьте PHP и PHP-FPM
Проверить стоит версию PHP, PHP-FPM, workers, memory_limit, timeouts, error log и slow log. Не надо ставить новый PHP «наверняка»: старый плагин или тема могут оказаться несовместимы.
Ищите в логах Fatal error, Allowed memory size exhausted, Maximum execution time exceeded и upstream timed out. Если PHP упирается в timeout или память, минификация JavaScript проблему не исправит.
Найдите медленный плагин или внешний запрос
На staging или при контролируемой диагностике Query Monitor помогает увидеть время генерации, SQL queries, HTTP API calls, PHP errors и hooks. Аномалия важнее количества таблиц: например, HTTP-запрос к CRM занял 2.7 секунды.
Проверяйте конкретный плагин, а не отключайте всё. Сценарий «обновили Plugin X → сайт стал медленным → отключили только Plugin X → время снизилось с 3.1 до 0.7 s» даёт доказательство. Внешний CRM, доставка, платежи, SMTP, антиспам или custom API могут синхронно задерживать HTML.
↑ К оглавлениюПроверьте базу данных
Ищите долгий SELECT, повторяющиеся queries, большое количество SQL, тяжёлые meta queries, autoloaded options и WooCommerce queries. Особенно часто проверяют wp_options, wp_postmeta и таблицы WooCommerce.
Не начинайте с кнопки Optimize Database. Для autoloaded options сначала определите владельца данных, сделайте backup и поймите назначение. Удалять записи удалённых плагинов или serialized objects только по названию нельзя.
↑ К оглавлениюПоймите, не тормозит ли сама тема
Тяжёлая тема может одновременно использовать page builder, гигантский CSS bundle, несколько JavaScript libraries, slider, animations, огромный DOM и код функций, которых на странице нет. В таком случае cache, Redis, CDN и минификация дадут всё меньший эффект.
На staging сделайте одинаковый замер текущей страницы и лёгкой тестовой темы: сравните TTFB, Page load, DOM и JS. Если переход с 5.8 до 1.7 секунды подтверждён замером, тему нельзя игнорировать. Если при этом отдельно тормозит вход в административную часть, сравните её с инструкцией по проблемам входа в админку WordPress. Не обещайте ускорить любой WordPress без изменения темы до диагностики.
↑ К оглавлениюПроверьте WP-Cron и фоновые задачи
Проверьте WP-Cron, scheduled events, WooCommerce Action Scheduler и очереди интеграций. Подозрительны тысячи pending actions или задача, которая падает, запускается снова и создаёт нагрузку.
Не очищайте очередь целиком: определите задачу, плагин-владелец и причину, по которой она не завершается.
↑ К оглавлениюПроверьте кеш и Cloudflare
Сравнивайте cached request и uncached request: кеш может дать 70 ms, а origin — 3.8 s. Для WooCommerce нельзя бездумно кешировать /cart/, /checkout/, /my-account/ и персональные данные.
Cloudflare CDN хорошо доставляет CSS, JS, изображения и шрифты. APO может кешировать HTML WordPress на edge, но HIT не означает, что origin, PHP, админка или checkout стали быстрее.
curl -svo /dev/null \
-A "CF" "https://example.ru/" \
-H "accept: text/html" 2>&1 \
| grep 'cf-cache-status\|cf-edge\|cf-apo-via'Ищите cf-cache-status, cf-apo-via и cf-edge-cache. Cookies могут правильно приводить к BYPASS. Проверяйте один слой кеша за раз и не включайте Cache Everything для WordPress/WooCommerce вслепую.
Проверьте frontend и изображения
Базовую оптимизацию изображений считаем выполненной, но в Network полезно проверить размер ресурсов. Если вся графика занимает 800 KB, а TTFB равен 3.5 s, обсуждать WebP бессмысленно. Когда HTML приходит быстро, проверяйте размер JS, long tasks, DOM, layout, rendering и third-party scripts.
размер JS
длительные tasks
количество scripts
DOM size
layout / rendering
third-party scriptsНе гонитесь за PageSpeed 100
Цель — быстрый реальный сайт, а не 100/100 любой ценой. Нельзя ради пары баллов ломать checkout, задерживать нужный JavaScript, портить форму или агрессивно кешировать динамический контент.
↑ К оглавлениюПрактический порядок ускорения WordPress
1. DevTools Network → 2. TTFB через curl → 3. сравнить страницы
4. статический файл vs WordPress → 5. CPU / RAM / disk
6. PHP / PHP-FPM → 7. Query Monitor / logs → 8. SQL queries
9. HTTP API calls → 10. плагины → 11. тема → 12. WP-Cron
13. cache HIT vs MISS → 14. Cloudflare / APO → 15. JS / DOM
16. повторный замерПосле каждого изменения измеряйте снова
Если было TTFB = 3.1 s, после отключения одного проблемного HTTP-запроса стало 0.8 s, результат доказан. Если было 3.1 s и стало 3.0 s, эта оптимизация почти ничего не изменила.
ДО ПОСЛЕ
Home TTFB 2.8 s Home TTFB 0.5 s
Article TTFB 2.6 s Article TTFB 0.5 s
Checkout TTFB 4.9 s Checkout TTFB 1.3 s
Page load 6.2 s Page load 2.0 sЧастые вопросы
Как быстро понять, почему WordPress медленный?
Зафиксируйте TTFB, время полной загрузки и сравните несколько страниц. Затем отделите backend от frontend и проверяйте сервер, PHP, базу, плагины и внешние запросы по очереди.
Всегда ли можно ускорить WordPress без замены темы?
Нет. Если сама тема создаёт большой DOM, тяжёлый CSS и JavaScript, её архитектура может быть главным узким местом. Это нужно подтвердить одинаковыми замерами на staging.
Какой плагин лучше всего ускоряет WordPress?
Универсального ответа нет. Сначала найдите конкретную причину и повторным замером подтвердите эффект одного изменения, а не устанавливайте плагины наугад.
Поможет ли более мощный сервер?
Только если ресурсы сервера действительно являются узким местом. Сначала проверьте CPU, RAM, swap, диск, PHP и базу данных, иначе перенос может не изменить результат.
Redis ускоряет WordPress?
Redis может помочь в подходящем сценарии, но не исправит медленный внешний API, тяжёлую тему или конкретный плохой SQL-запрос. Эффект нужно измерить до и после.
Почему сайт быстрый, а админка WordPress медленная?
Админка может выполнять другие запросы, работать с большим числом плагинов, cron-задач или тяжёлой базой. Сравнивайте frontend, /wp-admin/ и конкретные запросы.
Cloudflare ускоряет WordPress?
Cloudflare хорошо ускоряет доставку статики, а APO может отдавать кешированный HTML с edge. Но cache HIT не означает, что origin, PHP или checkout стали быстрее.
Можно ли получить PageSpeed 100?
Цель — быстрый реальный пользовательский сценарий, а не число любой ценой. Нельзя ради баллов ломать checkout, формы, нужный JavaScript или динамический контент.
Если WordPress всё равно работает медленно
После нормальной диагностики должно появиться конкретное узкое место: сервер, PHP, SQL query, plugin, API, тема, checkout или frontend.
Если сайт коммерческий, особенно WooCommerce с оплатами и интеграциями, перед изменениями лучше иметь backup, не отключать компоненты массово и проверять один шаг за другим.