Как ускорить WordPress: от кеша до NVMe-диска

Ускорить WordPress в 3–10 раз реально без переписывания темы и покупки дорогого сервера — большинство сайтов тормозят по одним и тем же причинам. Медленный диск хостинга, отсутствие кеша, PHP без OPcache, сотня autoload-опций в базе и три мегабайта несжатых картинок на главной. В этой статье разберём оптимизацию WordPress по слоям: от фундамента (VPS и NVMe-диск) до кеширования страниц, Redis и чистки базы данных. Все команды и конфиги проверены на Ubuntu 24.04 LTS с Nginx и PHP 8.3. После каждого шага будет понятно, что именно и насколько ускорилось.

Шаг 0. Измеряем, что именно тормозит

Оптимизировать вслепую бессмысленно. Сначала снимите две метрики.

TTFB (время до первого байта) — показывает скорость серверной части:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s, всего: %{time_total}s\n" https://ваш-сайт.ru/

Ориентиры: до 200 мс — отлично, 200–600 мс — есть над чем работать, больше 600 мс — сервер или база явно перегружены. Если TTFB хороший, а страница всё равно грузится долго, проблема во фронтенде: картинках, скриптах, шрифтах — это покажет PageSpeed Insights.

Медленные запросы и плагины — установите плагин Query Monitor. Он показывает, какие SQL-запросы и какие плагины съедают время генерации страницы. Нередко один «плагин-комбайн» добавляет 300–500 мс на каждый запрос.

Шаг 1. Фундамент: быстрый VPS и NVMe-диск

WordPress — это тысячи мелких чтений файлов и обращений к MySQL на каждую страницу. На виртуальном хостинге с перегруженными соседями и SATA-дисками никакие плагины не спасут. Минимальный набор для быстрого WordPress:

• NVMe-диск — случайное чтение мелких блоков в 5–7 раз быстрее SSD, а именно из таких операций состоит работа MySQL и загрузка PHP-файлов;
• KVM-виртуализация — выделенные, а не «общие» ресурсы CPU и RAM;
• 4+ ГБ RAM — чтобы поместились MySQL, PHP-FPM, OPcache и Redis;
• свежий PHP 8.3 — он на 20–40% быстрее PHP 7.4 на реальных сайтах WordPress.

Например, у Cheap-Host под WordPress хорошо подходит тариф Pro — 12 vCPU, 16 ГБ RAM и 128 ГБ NVMe за 750 ₽/мес: этого хватает и на сайт с десятками тысяч посетителей, и на Redis с запасом. Сервер выдаётся за 45–60 секунд. Если вы ещё не переехали с хостинга, начните с руководства по установке WordPress на VPS.

Шаг 2. Кеширование страниц — главные 80% ускорения

Идея простая: страница блога не меняется от посетителя к посетителю, значит незачем каждый раз запускать PHP и дёргать MySQL. Один раз сгенерировали — отдаём готовый HTML из кеша. Самый быстрый вариант — fastcgi_cache прямо в Nginx: закешированную страницу он отдаёт за 5–30 мс, вообще не обращаясь к PHP.

Добавьте в /etc/nginx/nginx.conf внутрь блока http {} (или отдельным файлом в conf.d/):

fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WPCACHE:100m inactive=60m max_size=512m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

А в server-блоке сайта настройте исключения (админка, авторизованные пользователи, POST-запросы) и сам кеш:

set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap") { set $skip_cache 1; }
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") { set $skip_cache 1; }

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_cache WPCACHE;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    add_header X-Cache $upstream_cache_status;
}

Проверьте конфиг и перезагрузите Nginx:

sudo nginx -t && sudo systemctl reload nginx

Теперь откройте страницу дважды и посмотрите заголовок X-Cache: первый запрос вернёт MISS, второй — HIT. Чтобы кеш сбрасывался при публикации записей, поставьте плагин Nginx Helper. Если возиться с конфигами не хочется, плагины WP Super Cache или W3 Total Cache дадут похожий эффект, просто чуть медленнее — страницу всё же будет отдавать PHP.

Шаг 3. OPcache и PHP-FPM: разгоняем сам PHP

OPcache хранит скомпилированный байт-код PHP в памяти, избавляя сервер от повторной компиляции сотен файлов WordPress на каждый запрос. В Ubuntu 24.04 он включён по умолчанию, но со скромными лимитами. Создайте файл /etc/php/8.3/fpm/conf.d/90-opcache-tune.ini:

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.interned_strings_buffer=32
opcache.validate_timestamps=1
opcache.revalidate_freq=60

И перезапустите PHP-FPM:

sudo systemctl restart php8.3-fpm

Второй резерв — сам PHP-FPM: количество воркеров pm.max_children должно соответствовать вашей RAM, иначе под наплывом посетителей запросы встанут в очередь. Как рассчитать пул под память сервера, мы подробно разбирали в статье об оптимизации PHP-FPM.

Шаг 4. Redis: объектный кеш для базы данных

Кеш страниц не помогает залогиненным пользователям, WooCommerce-корзинам и админке — эти страницы всегда генерируются заново. Здесь работает объектный кеш: WordPress складывает результаты SQL-запросов в Redis и при повторном обращении берёт их из памяти вместо MySQL. Установка занимает пять минут:

sudo apt update
sudo apt install redis-server php8.3-redis
sudo systemctl enable --now redis-server

Затем добавьте в wp-config.php строку define('WP_REDIS_HOST', '127.0.0.1');, установите плагин Redis Object Cache и нажмите в его настройках Enable Object Cache. Админка и динамические страницы обычно ускоряются на 30–50%. Подробнее о том, как устроен Redis и что ещё он умеет, — в статье о кешировании с Redis.

Шаг 5. Фронтенд: картинки, сжатие, ленивая загрузка

Когда сервер отвечает быстро, остаётся уменьшить сам объём страницы:

• Картинки в WebP/AVIF. Плагины Converter for Media или EWWW конвертируют библиотеку автоматически; типичная экономия — 30–60% веса без видимой потери качества.
• Ленивая загрузка. WordPress сам добавляет loading="lazy" картинкам вне первого экрана — просто не отключайте это темой.
• Сжатие текста. Gzip или Brotli уменьшают HTML, CSS и JS на 70–85%. Как включить оба алгоритма в Nginx — в отдельном руководстве по Gzip и Brotli.
• Меньше плагинов. Каждый активный плагин — это код, который выполняется на каждом запросе. Раз в квартал удаляйте всё, чем не пользуетесь.

Шаг 6. База данных и WP-Cron

Со временем база WordPress обрастает мусором: ревизии записей, спам-комментарии, транзиенты истёкших плагинов. Особенно вредны autoload-опции — они загружаются на каждой странице. Проверить их объём:

mysql -u wp_user -p -e "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb FROM wp_db.wp_options WHERE autoload IN ('yes','on');"

Больше 800–1000 КБ — повод почистить: обычно виноваты опции давно удалённых плагинов. Для регулярной уборки подойдёт плагин WP-Optimize (ревизии, транзиенты, оптимизация таблиц).

Второй пожиратель ресурсов — WP-Cron: он проверяет расписание задач при каждом визите посетителя. Отключите его в wp-config.php:

define('DISABLE_WP_CRON', true);

И запускайте по-настоящему, раз в пять минут, через системный cron:

*/5 * * * * curl -s https://ваш-сайт.ru/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Что и сколько даёт: сводная таблица

Порядок именно такой: сначала сервер и кеш, потом фронтенд. Оптимизировать картинки на сайте с TTFB в секунду — всё равно что полировать кузов машины без двигателя.

FAQ

Какой один шаг даст максимальное ускорение WordPress?

Кеширование готовых страниц. Пока страница в кеше, PHP и MySQL вообще не запускаются, и время ответа падает с 300–800 мс до 5–30 мс. Это даёт больше, чем все остальные оптимизации вместе взятые.

Что лучше для кеша — плагин или fastcgi_cache в Nginx?

fastcgi_cache быстрее: Nginx отдаёт страницу, не поднимая PHP. Плагины проще в настройке и сами сбрасывают кеш при публикации. Компромисс — fastcgi_cache плюс плагин Nginx Helper для его очистки.

Сколько ресурсов VPS нужно быстрому WordPress?

Сайту до 30–50 тысяч посетителей в сутки с настроенным кешем хватает 2–4 vCPU и 4–8 ГБ RAM. С запасом под Redis и рост трафика удобен тариф Pro у Cheap-Host: 12 vCPU, 16 ГБ RAM, NVMe — 750 ₽/мес.

Помогают ли плагины-оптимизаторы «одной кнопкой»?

Частично: они сжимают картинки и откладывают скрипты, но не лечат медленный хостинг и тяжёлые SQL-запросы. Сначала серверная часть, потом фронтенд-плагины.

Почему WordPress тормозит даже без посетителей?

Обычно виноваты медленный диск, раздутая таблица wp_options, тяжёлые плагины и WP-Cron. Измерьте TTFB через curl и профилируйте запросы Query Monitor — узкое место найдётся за вечер.

Вывод

Быстрый WordPress — это не магия, а последовательность: приличный сервер с NVMe, кеш страниц, OPcache, Redis, лёгкий фронтенд и чистая база. Один вечер работы по этому чек-листу обычно превращает сайт с TTFB 600–800 мс в сайт, отвечающий за 30–50 мс. Если для этой задачи вам нужен сервер — у Cheap-Host тариф Pro за 750 ₽/мес: 12 vCPU, 16 ГБ RAM, NVMe-диск, KVM, безлимитный трафик и выдача сервера за минуту. Посмотреть все тарифы можно на cheap-host.onl.