Как настроить OPcache в WordPress и убрать лишнюю нагрузку на сервер

Если WordPress на обычном хостинге начинает заметно тормозить без видимой причины, OPcache — один из первых пунктов, который стоит проверить. Это не «магическая оптимизация», а нормальный механизм PHP, который хранит скомпилированный байткод в памяти и снижает количество повторных разборов PHP-файлов.

На практике проблема обычно выглядит так: админка открывается медленно, страницы сайта долго генерируются, а на сервере при этом нет явной ошибки в логах. В такой ситуации важно не ставить кеш-плагины вслепую, а сначала понять, включён ли OPcache, как он настроен и не сбрасывается ли он слишком часто.

Как понять, что проблема именно в PHP, а не в теме или плагинах

Сначала отделите серверную часть от WordPress-логики. Если медленно открываются и фронтенд, и /wp-admin/, а в панели хостинга видно высокую нагрузку на CPU именно в моменты генерации страниц, OPcache имеет смысл проверить в первую очередь.

Быстрая диагностика

Откройте wp-admin и несколько обычных страниц в режиме инкогнито.
Сравните время ответа до и после очистки кеша страницы, если он есть.
Посмотрите, не растёт ли нагрузка после каждого обновления страницы.
Проверьте, включён ли OPcache в текущем PHP-пуле.

Если у вас есть доступ к серверу, самый простой способ — создать временный файл с phpinfo() и проверить блок OPcache. Но на рабочем сайте лучше не оставлять такой файл надолго.

<?php
phpinfo();

После проверки файл нужно удалить. Если доступа к серверу нет, можно использовать плагин для просмотра информации о PHP, но для постоянной диагностики это не лучший вариант.

Что именно нужно настроить в OPcache

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

Базовые параметры, на которые стоит смотреть

opcache.enable — должен быть включён для веб-SAPI.
opcache.memory_consumption — объём памяти под кеш байткода.
opcache.max_accelerated_files — лимит на количество кешируемых файлов.
opcache.revalidate_freq — как часто PHP проверяет изменения файлов.
opcache.validate_timestamps — проверять ли изменения файлов вообще.

Для обычного WordPress-сайта опаснее всего не нехватка «оптимизаций», а слишком частая проверка файлов. Если validate_timestamps включён и revalidate_freq стоит слишком низко, сервер будет лишний раз ходить по файловой системе.

Пошаговая настройка OPcache на сервере

Ниже — рабочая схема, если у вас есть доступ к конфигурации PHP. Точные пути зависят от окружения: PHP-FPM, Apache mod_php, панель хостинга или отдельный сервер. Логика одна и та же.

Шаг 1. Найдите активный ini-файл

Сначала определите, какой конфиг PHP реально используется. Это можно увидеть через phpinfo() или командой в консоли, если есть SSH:

php --ini

В выводе будет основной php.ini и дополнительные файлы из каталога conf.d.

Шаг 2. Проверьте, подключён ли модуль OPcache

В CLI и в вебе это может отличаться, поэтому проверяйте именно веб-окружение. Если модуль не загружен, его нужно включить на уровне PHP-пакета или панели хостинга.

Шаг 3. Добавьте базовые настройки

Пример конфигурации для большинства обычных сайтов WordPress. Это не универсальный рецепт, а стартовая точка, которую потом проверяют по факту нагрузки и объёму сайта.

[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1

Если деплой у вас ручной и вы после обновления сайта умеете очищать кеш на сервере, иногда используют opcache.validate_timestamps=0. Но для обычного WordPress это рискованнее: изменения файлов не подхватятся автоматически, и после обновления темы или плагина можно получить странное поведение до ручной очистки OPcache.

Шаг 4. Перезапустите PHP-FPM или веб-сервер

Без перезапуска новые параметры могут не примениться. На сервере с PHP-FPM обычно перезапускают именно пул PHP, а не весь веб-сервер. На shared-хостинге это делает провайдер или панель.

Когда лучше не трогать validate_timestamps

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

Подход	Что даёт	Риск
OPcache с проверкой файлов	Безопаснее для сайтов с частыми обновлениями	Чуть больше обращений к файловой системе
OPcache без проверки файлов	Максимально предсказуемая скорость	Нужна ручная очистка после деплоя
Только кеш-плагин без OPcache	Ускоряет HTML на уровне WordPress	Не снимает нагрузку с PHP

Если у вас сайт обновляется руками раз в неделю и вы контролируете деплой, можно рассмотреть более жёсткую схему. Если сайт ведут несколько человек, безопаснее оставить автоматическую проверку.

Как проверить, что OPcache реально работает

После настройки не ограничивайтесь тем, что «ошибок нет». Нужна проверка по факту.

Проверка через phpinfo

В блоке OPcache смотрите, что модуль активен, а параметры соответствуют тем, которые вы задали. Если значения не совпадают, значит, редактируется не тот конфиг или PHP-пул не был перезапущен.

Проверка по поведению сайта

Повторное открытие страниц стало стабильнее по времени ответа.
После первого запроса нагрузка на CPU ниже, чем до настройки.
Админка перестала «проседать» на простых действиях без тяжёлых плагинов.

Если у вас есть доступ к логам или метрикам хостинга, сравните нагрузку до и после в одинаковые периоды. Иначе легко принять эффект от обычного кеша страниц за результат OPcache.

Частые ошибки и как их исправить

OPcache включили в CLI, но не в вебе

Это бывает, когда проверяют только php -v или php --ini. WordPress работает через веб-SAPI, и там конфигурация может быть другой. Проверяйте именно через браузер или через тот PHP-пул, который обслуживает сайт.

Слишком маленький лимит памяти

Если memory_consumption слишком низкий, кеш будет быстро вытесняться. Внешне это выглядит как «OPcache включён, но толку мало». Для большого набора плагинов и темы с собственным кодом 64 МБ может оказаться мало.

После обновления сайта изменения не видны

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

Путают OPcache и page cache

OPcache ускоряет выполнение PHP-кода. Он не заменяет кеш страниц, не решает проблемы тяжёлых запросов к базе и не исправляет медленные внешние API. Если сайт тормозит из-за медленной темы или кривого плагина, OPcache только уменьшит ущерб, но не уберёт причину.

Чек-лист перед вводом в работу

Проверен активный PHP-пул сайта.
Убедились, что OPcache включён именно в веб-окружении.
Настроен разумный объём памяти под кеш.
Не отключена проверка файлов без необходимости.
После правок PHP-FPM или веб-сервер перезапущен.
Проверено, что обновления темы и плагинов отображаются корректно.

Что ещё имеет смысл сделать рядом с OPcache

Если сайт на WordPress уже упирается в производительность, OPcache лучше рассматривать как часть общей настройки, а не как отдельный «ускоритель». Проверьте тяжёлые плагины, количество автозагрузки в базе, лишние cron-задачи и ненужные скрипты в теме. Иногда именно они создают ощущение, что сервер «не тянет», хотя проблема не в PHP как таковом.

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