Page cache и object cache в WordPress: что ускоряет каждый слой

В WordPress словом «кеш» называют несколько независимых механизмов. Page cache хранит готовый HTML, object cache — результаты запросов и вычислений, OPcache — скомпилированный PHP-код, а браузерный кеш — изображения, CSS и JavaScript у посетителя. Один переключатель не включает их все.

Начинайте с измерения и одного слоя. Иначе при устаревшей странице будет непонятно, где она сохранена и какой механизм нужно очищать.

Измерьте страницу без входа и после входа

Проверяйте один URL несколькими последовательными запросами. Команда выводит код, время до первого байта и общее время, не сохраняя тело:

curl --silent --show-error --output /dev/null \
  --write-out 'code=%{http_code} start=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/article/

Повторите её несколько раз с другого компьютера. Первый запрос после очистки обычно медленнее последующих, но вывод зависит от сети; для сравнения сохраняйте время и условия. Отдельно измеряйте административную часть и страницу под авторизованным пользователем.

Настройте page cache для публичных ответов

Page cache полезен для статей и рубрик, одинаковых для всех анонимных посетителей. Он должен обходиться при cookie входа, POST-запросе, preview, корзине, оформлении заказа и других персональных URL. Точные правила зависят от плагина и темы.

После включения проверьте заголовки и изменение времени:

curl --silent --dump-header - --output /dev/null https://example.com/article/
curl --silent --dump-header - --output /dev/null https://example.com/article/

Ищите документированный заголовок HIT/MISS вашего решения, а не угадывайте его имя. Затем отредактируйте статью и убедитесь, что новый текст появляется без ручного удаления файлов на сервере. Неудачная очистка — причина не включать кеш в production.

Object cache ускоряет сборку динамической страницы

WordPress хранит объекты только в рамках запроса, если нет постоянного backend. Drop-in wp-content/object-cache.php подключает Redis или Memcached, чтобы повторно использовать значения между запросами. Это помогает при частых обращениях к базе, но добавляет ещё одну службу.

Проверьте состояние штатными средствами выбранного плагина и WP-CLI:

wp --path=/srv/www/example.com/current cache flush
wp --path=/srv/www/example.com/current transient delete --all

Обе команды удаляют кешируемые значения, поэтому первый запрос станет дороже. После них контент обязан сохраниться. Если Redis недоступен, сайт должен либо корректно вернуться к базе, либо быстро сообщить понятную ошибку — это проверяют на staging до эксплуатации.

Не публикуйте Redis в интернет и не используйте одну базу кеша для staging и production. Совпадающие ключи могут смешать данные разных окружений.

Проверяйте персонализацию двумя сессиями

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

При утечке персонального ответа немедленно отключите page cache, очистите его и исправьте условия bypass. Увеличение TTL здесь не помогает.

План очистки является частью настройки

Запишите, что происходит при публикации, смене меню, обновлении темы и откате. Очистка всего кеша допустима как аварийная мера, но создаёт всплеск нагрузки. В обычной работе лучше инвалидировать только затронутые URL и связанные архивы.

Сравнивайте p95 времени ответа, загрузку PHP и число запросов базы до и после. Если ускорения нет, дополнительный сервис только усложняет диагностику. Общая схема слоёв описана в архитектуре WordPress, а статические файлы требуют отдельной оптимизации изображений.

Источники

• WordPress: cache
• WordPress: wp-config cache settings
• WordPress: object cache
• HTTP caching specification