Как ускорить сайт на WordPress и настроить кэширование на VPS, чтобы Core Web Vitals были зелёными?

Core Web Vitals проваливаются не из-за одной причины, а из-за связки: тяжёлые темы и плагины, отсутствие кэша на уровне Nginx и объекта, медленный TTFB из-за неоптимизированного PHP-FPM и MySQL, неконтролируемые внешние скрипты. На VPS без правильной конфигурации каждый запрос уходит в PHP и БД, что даёт TTFB 800–2000 мс и красный LCP. Кэширование плагином без серверного слоя не решает проблему при пиковом трафике и авторизованных пользователях.

Ниже — практический разбор с критериями и следующим шагом. Связанные услуги: каталог, AI Boost Team, стать клиентом.

Почему VPS без серверного кэша тормозит WordPress

Зелёные Core Web Vitals на WordPress упираются не в тему, а в TTFB, который на VPS без серверного кэша держится в районе 800–2000 мс. Это не «плохой хостинг». Это нормальное поведение стека Nginx + PHP-FPM + MySQL, когда каждый анонимный визит прогоняется через PHP и базу.

Схема простая и от этого обидная. Пришёл посетитель на главную. Nginx отдаёт запрос в PHP-FPM. PHP поднимает WordPress, тот лезет в MySQL за опциями, меню, постами, метаданными. MySQL отвечает. PHP собирает HTML. Nginx отдаёт его браузеру. И так на каждый запрос. Пока трафик маленький, вы этого не замечаете. Как только пошёл рост или реклама дала пик, TTFB растёт, LCP краснеет, конверсия падает.

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

Что реально ограничивает LCP? TTFB. Пока сервер думает 800–2000 мс, браузер не начинает получать HTML. Никакой критический CSS и отложенный JS это не компенсируют. Сначала серверная отдача, потом фронтенд. В обратном порядке не работает.

Если у вас VPS на 2–4 vCPU и 4–8 ГБ RAM без выделенного DevOps — это не приговор. Но настраивать придётся руками. Ниже — порядок действий, который даёт предсказуемый результат, и границы, где он перестаёт работать.

Замер базовых метрик до изменений

Без baseline вы потом не докажете себе, что что-то улучшилось. И не поймёте, где узкое место. Поэтому первый шаг — не трогать конфиги, а зафиксировать состояние.

Что снять:

• PageSpeed Insights по мобильной версии: LCP, INP, CLS. Ориентиры зелёной зоны — LCP до 2,5 с, INP до 200 мс, CLS до 0,1.
• CrUX, если домен уже набрал трафик: там реальные данные пользователей, а не лабораторные.
• TTFB через curl -w на анонимном запросе. Не из админки, не под своим логином — именно анонимно, иначе замер врёт.

Замер TTFB делайте несколько раз подряд и на разных страницах: главная, категория, карточка товара или статьи. Разброс сам покажет, где кэш не работает. Если главная отдаётся за 150–300 мс, а карточка за 1,8 с — проблема в конкретных запросах к базе, а не в сервере целиком.

Запишите цифры в таблицу. Дальше все правки сверяете только с ней. Иначе через неделю будете спорить с собой, стало лучше или показалось.

Отдельно проверьте, сколько у вас плагинов и сколько внешних доменов грузит страница. Это не метрика, но это причина. Если плагинов 40 и половина тянет скрипты со сторонних CDN — серверный кэш ускорит отдачу HTML, но LCP и INP останутся красными.

Nginx fastcgi_cache: полностраничный кэш для анонимных

Это главный слой. Nginx отдаёт готовый HTML из кэша, не заходя в PHP. TTFB для анонимных запросов падает до 200–300 мс и ниже. Это ориентир, а не гарантия: цифра зависит от вашего железа и конфигурации.

Ключ кэша строится по URL и cookie. Простая схема: метод запроса, схема, хост, URI. Плюс учёт cookie, чтобы не отдать авторизованному пользователю страницу анонимного.

Что обязательно исключить из кэша:

• wp-admin и wp-login — админка не кэшируется никогда.
• Корзину и оформление заказа, если у вас WooCommerce: cookie woocommerce_items_in_cart, woocommerce_cart_hash.
• Авторизованных: cookie wordpress_logged_in_*.
• Страницы с формами, где нужен свежий nonce.

TTL ставьте разумный. Для контентного сайта 24 часа нормально, если настроен принудительный purge при публикации. Без purge вы получите устаревший контент и вопросы от клиентов, почему на сайте старая цена.

Purge цепляйте к хукам WordPress: сохранение поста, обновление меню, изменение товара. Тогда кэш живёт долго, но обновляется в момент правки. Это тот случай, когда «настроил и забыл» реально работает.

Оговорка: fastcgi_cache не поможет, если у вас постоянный трафик авторизованных пользователей. Личный кабинет, B2B-портал, подписка — там полностраничный кэш неприменим, и вы упираетесь в скорость PHP и базы. Для таких сценариев смотрите каталог решений под нагрузку, а не пытайтесь выжать кэш там, где его быть не может.

Redis Object Cache и OPcache

Fastcgi_cache снимает нагрузку с анонимных. Но остаются авторизованные, админка, AJAX-запросы и всё, что идёт мимо кэша. Там каждый запрос снова бьёт в MySQL. Поэтому второй слой — объектный кэш.

Redis Object Cache подключается через плагин и перехватывает повторяющиеся запросы WordPress к базе: опции, транзиенты, метаданные. На повторных запросах MySQL разгружается заметно. Это не ускорит первую отдачу HTML, но уберёт лишние обращения к базе на каждом некэшированном запросе.

OPcache — отдельная история. Он кэширует скомпилированный PHP-код, чтобы не парсить файлы на каждый запрос. На продакшене ставьте validate_timestamps=0. Это значит, что PHP не проверяет изменения файлов на диске. Быстрее, но требует сброса OPcache при деплое. Если забудете — будете час искать, почему правки не применяются.

PHP-FPM настраивается под RAM вашего VPS. pm=dynamic, разумный max_children. Формула простая: считаете, сколько памяти съедает один процесс PHP, и делите доступную RAM с запасом. Если поставить max_children слишком много, сервер начнёт свопить и станет медленнее, чем до оптимизации. Если слишком мало — запросы встанут в очередь.

Для SMB-сайта с умеренным трафиком 2 vCPU и 4 ГБ RAM обычно хватает, если настроены fastcgi_cache, Redis и OPcache. При росте трафика или тяжёлых плагинах потребуется больше ресурсов. Точный порог без замеров не назову — он зависит от вашего профиля нагрузки.

Если не хотите считать max_children вручную и подбирать конфиги под свой стек, это можно закрыть через заявку на аудит конфигурации: инженер снимет baseline, посчитает пулы и отдаст готовые параметры.

Оптимизация фронтенда под Core Web Vitals

Серверная часть даёт TTFB. Но LCP, INP и CLS — это уже фронтенд. И здесь работает не магия, а сокращение.

Что делать по порядку:

• Критический CSS инлайном, остальное — отложенно. Это ускоряет первую отрисовку.
• JS грузить с defer или async, кроме того, что реально нужно сразу. Каждый синхронный скрипт в head — это задержка.
• Изображения в WebP или AVIF. И обязательно фиксированные width/height, иначе CLS будет прыгать.
• Lazy-load для всего, что ниже первого экрана. Но не для LCP-изображения — его грузите сразу.
• Сократить плагины. Каждый плагин — это CSS, JS и запросы к базе. Если плагин делает то, что можно сделать 10 строками в functions.php, уберите плагин.
• Сократить внешние домены. Каждый сторонний скрипт — это ещё один DNS, TLS и ожидание. Аналитика, чаты, шрифты, виджеты — всё это складывается.

Здесь важно не увлечься. Цель — не «идеальный сайт», а зелёные метрики на реальном трафике. Иногда достаточно убрать два тяжёлых плагина и перевести картинки в WebP, чтобы LCP ушёл в зелёную зону. Иногда нужно переписывать шаблон. Без замера после каждого шага вы не поймёте, что сработало.

CDN для статики даёт эффект, когда у вас распределённая аудитория или сервер физически далеко от пользователей. Если все посетители из одного региона, а сервер рядом — выигрыш будет скромным. Не ставьте CDN «на всякий случай»: это ещё один слой, который надо настраивать и отлаживать.

До / после: что меняется на каждом слое

Цифры в правой колонке — ориентиры, а не обещание. Результат зависит от вашей темы, плагинов и профиля трафика. Кто обещает конкретные метрики без доступа к вашему серверу — продаёт воздух.

Проверка результата и типичные ошибки

После всех правок повторите замер: PageSpeed Insights, CrUX, curl -w. Сравните с baseline. Если TTFB упал, а LCP всё ещё красный — проблема на фронтенде, возвращайтесь к секции выше. Если TTFB не изменился — кэш не работает, проверяйте ключи и исключения.

Типичные ошибки, которые ломают всё:

• Кэшируют админку или корзину. Пользователь видит чужой контент. Это не баг, это ваша конфигурация.
• Забыли purge. На сайте старая цена, старый баннер, старый пост. Клиенты звонят и спрашивают.
• Поставили max_children больше, чем тянет RAM. Сервер начал свопить, стало хуже, чем было.
• Включили validate_timestamps=0 и забыли сбрасывать OPcache при деплое. Правки не применяются, вы ищете причину в коде.
• Оставили 40 плагинов и ждут зелёных метрик. Серверный кэш ускорит отдачу HTML, но фронтенд останется тяжёлым.

Отдельно про CDN. Он даёт эффект при географически распределённой аудитории или когда сервер далеко. Если все пользователи в одном регионе и сервер рядом — выигрыш будет небольшим, а слой добавится. Не усложняйте без причины.

Когда это не сработает

Подход не сработает, если сайт держится на тяжёлой теме с десятками плагинов и внешними скриптами, которые нельзя убрать. Кэш ускорит отдачу HTML, но LCP и INP останутся красными. Тут нужна пересборка фронтенда, а не настройка сервера.

Не поможет при постоянном трафике авторизованных пользователей. Полностраничный кэш неприменим, и вы упираетесь в скорость PHP и базы. Личный кабинет, B2B-портал, подписка — это другой сценарий, там работает Redis, но не fastcgi_cache.

Не сработает, если на VPS не хватает ресурсов физически. 2 vCPU и 4 ГБ RAM — это потолок для умеренного трафика. При росте или тяжёлых плагинах потребуется больше. Порог, после которого VPS меняют на выделенный сервер, определяется замерами: смотрите TTFB, очереди PHP-FPM и нагрузку на MySQL в пиковые часы.

И не сработает, если вы не замеряете. Настройка «по гайду» без baseline и повторного замера — это лотерея. Иногда попадает, чаще нет.

Повторить у себя за 7 дней

1. День 1–2. Снимите baseline: PageSpeed Insights, CrUX, curl -w на трёх типах страниц. Запишите в таблицу. Посчитайте плагины и внешние домены.
2. День 3–5. Настройте Nginx fastcgi_cache с ключом по URL и cookie, исключите админку, корзину и авторизованных. Подключите Redis Object Cache. Настройте OPcache с validate_timestamps=0 и PHP-FPM под RAM.
3. День 6–7. Оптимизируйте фронтенд: критический CSS, defer для JS, WebP/AVIF, фиксированные размеры изображений. Повторите замер и сравните с baseline. Если TTFB упал, а LCP красный — работайте с фронтендом. Если TTFB не изменился — проверяйте кэш.

Если после этих шагов метрики не в зелёной зоне, проблема глубже: тема, плагины или нехватка ресурсов. Тогда смотрите решения по оптимизации WordPress или заказывайте аудит — вслепую дальше двигаться дороже, чем один раз разобраться.

FAQ

Достаточно ли плагина кэширования WordPress, чтобы получить зелёные Core Web Vitals на VPS?

Нет. Плагин кэширует HTML, но запрос всё равно проходит через PHP и часто через MySQL. Без Nginx fastcgi_cache и Redis TTFB остаётся высоким, а при пиках и авторизованных сессиях кэш не срабатывает вовсе.

Какой TTFB считать целевым?

Ориентир — до 200–300 мс на серверной стороне для анонимных запросов с кэшем. LCP при этом должен укладываться в 2,5 с на мобильных. Это ориентир, а не гарантия: цифра зависит от вашего железа и конфигурации.

Что делать с авторизованными пользователями и корзиной?

Исключите их из fastcgi_cache по cookie (wordpress_logged_in, woocommerce_items_in_cart) и настройте отдельный пул PHP-FPM. Для них работает Redis Object Cache, но не полностраничный кэш.

Хватит ли 2 vCPU и 4 ГБ RAM?

Для SMB-сайта с умеренным трафиком — обычно да, если настроены Nginx fastcgi_cache, Redis и OPcache. При росте трафика или тяжёлых плагинах потребуется больше ресурсов. Точный порог определяется замерами, а не универсальной цифрой.

Почему после включения кэша контент не обновляется?

Не настроен purge. Кэш живёт по TTL, и без принудительного сброса при публикации