Настройка OPcache для сайта: ускорение PHP в 2026

OPcache я настраиваю почти на каждом проекте, где PHP ещё хоть как-то живой и не упирается в кеш на уровне фреймворка. На деле это один из самых дешёвых способов ускорить сайт: без переписывания кода, без миграции на новую CMS и без магии. Если у вас WordPress, Bitrix или Laravel на PHP 8.1–8.3, нормальная настройка OPcache часто даёт заметный выигрыш по TTFB и снимает лишнюю нагрузку с CPU.

Что такое OPcache и почему он важен

Грубо говоря, OPcache хранит уже скомпилированный PHP-код в памяти. Когда пользователь открывает страницу, PHP не разбирает файлы заново от запроса к запросу, а берёт готовый байткод из кеша. И это не «приятный бонус», а нормальная база для любого сайта, который не хочет тормозить на каждом хите.

На моей практике сайты без OPcache на PHP 8.1 или 8.2 часто показывают лишние 20–40% загрузки CPU под обычной нагрузкой. Особенно это видно на WordPress с кучей плагинов, на Bitrix с тяжёлыми компонентами и на Laravel-проектах, где автозагрузка классов и десятки файлов дергаются на каждом запросе. Если у вас ещё и MySQL 5.7, а хостинг не самый быстрый, то без OPcache картина становится совсем грустной.

Я обычно объясняю это клиентам просто: OPcache не ускоряет SQL-запросы и не уменьшает размер картинок, но он сильно сокращает «пустую работу» PHP. А её на среднем сайте больше, чем кажется.

Если вам нужно комплексное ускорение, OPcache почти всегда идёт в паре с другими вещами: кешированием в Битрикс, Redis, CDN, сжатием Gzip/Brotli и нормальной оптимизацией базы. Но именно OPcache я ставлю первым, потому что это один из самых простых и безопасных шагов.

Как работает OPcache в PHP 8.1, 8.2 и 8.3

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

В PHP 8.1, 8.2 и 8.3 поведение OPcache в целом похоже, но на практике 8.2 и 8.3 лучше чувствуют себя на современных серверах с достаточным объёмом RAM. У меня был клиент на Bitrix с PHP 8.1 и OPcache 64 MB: всё работало, но при большом количестве модулей кеш-фрагментация росла слишком быстро. После перехода на 128 MB и аккуратной настройки interned strings сайт стал стабильнее и быстрее по отклику.

Ещё важная деталь: OPcache не вечный. Он может инвалидироваться при деплое, при изменении файлов, при перезапуске PHP-FPM. Поэтому если у вас CI/CD, Git и автодеплой, нужно понимать, как именно очищается и прогревается кеш. Иначе можно получить странные просадки после выката.

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

Какие настройки OPcache стоит менять в первую очередь

На деле в OPcache куча параметров, но реально влияют на сайт не все. Я обычно начинаю с четырёх вещей: объём памяти, количество файлов, сохранение комментариев и частота проверки изменений. Всё остальное уже подбирается по ситуации.

Основные директивы, на которые я смотрю в первую очередь:

• opcache.enable — должен быть 1.
• opcache.memory_consumption — обычно 128 MB, иногда 256 MB для крупных проектов.
• opcache.interned_strings_buffer — 16–32 MB.
• opcache.max_accelerated_files — зависит от количества PHP-файлов.
• opcache.validate_timestamps — для продакшена часто 0, но не всегда.
• opcache.revalidate_freq — если timestamps включены, ставлю 60–300 секунд.

Если сайт маленький — корпоративный лендинг, каталог на WordPress, простая посадочная страница — хватит 64–128 MB. Если это интернет-магазин, битриксовый портал или Laravel-проект с административной частью и очередями, я обычно смотрю уже на 128–256 MB. И не надо экономить на этой памяти как на спичках. Это копейки по сравнению с выигрышем по скорости.

А ещё я бы отдельно смотрел на лимиты памяти PHP и MySQL. Если у PHP-FPM слишком маленький memory_limit, а OPcache раздувается, сервер начинает работать нервно. Особенно на VPS с 2 GB RAM, где на нём же крутится nginx, MySQL 8.0 и Redis.

Пример конфигурации OPcache для продакшена

Ниже — конфиг, который я часто беру как базу для сервера с PHP 8.2/8.3 и nginx. Это не «универсальная таблетка», но хороший старт для большинства проектов.

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit=0
opcache.jit_buffer_size=0
opcache.file_update_protection=2
opcache.max_wasted_percentage=5

Теперь коротко по смыслу. validate_timestamps=0 — это классика для продакшена, но только если у вас есть понятный деплой. Если сайт обновляется вручную через FTP, так делать нельзя, иначе изменения не подхватятся сразу. И вот тут люди часто сами себе создают проблему.

opcache.max_accelerated_files=100000 я ставлю с запасом. На небольшом сайте это не вредит, а на Bitrix и Laravel лишний запас полезен. У одного клиента на WordPress с WooCommerce и кучей расширений была смешная история: при значении 7963 кеш забивался почти мгновенно, а после повышения лимита сайт перестал «плавать» под нагрузкой.

Если у вас старый сайт на PHP 7.4, не надо держаться за него из принципа. Но если обновление пока не готово, OPcache всё равно даст толк. Просто не ждите чудес. Сначала лучше провести аудит и понять, почему сайт вообще медленный: это может быть база, код, плагины или кривой хостинг. По этому поводу у меня есть отдельная статья — почему сайт медленно работает и как это исправить.

Настройка OPcache на nginx и PHP-FPM

В реальной жизни OPcache живёт не сам по себе. Он работает через PHP-FPM, а значит, надо смотреть и на сам пул, и на перезапуск сервиса, и на логи. На серверах с nginx я обычно проверяю, не держит ли FPM слишком мало воркеров, не упирается ли в RAM и не убивает ли производительность лишний трешинг.

Пример, который часто использую для диагностики и базовой настройки:

server {
    listen 80;
    server_name example.ru;
    root /var/www/example.ru/public;

    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $document_root;
        fastcgi_read_timeout 120s;
    }

    location ~* \.(jpg|jpeg|png|gif|webp|avif|css|js|svg|ico)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        access_log off;
    }
}

Да, это не настройка OPcache в чистом виде. Но без нормального PHP-FPM и nginx весь эффект от кеша легко размазывается. На слабом хостинге я часто вижу ситуацию, когда OPcache включили, а сайт всё равно медленный из-за медленных upstream-ответов, очереди воркеров и постоянных 502/504 на пиках. Тогда надо смотреть уже шире — обратный прокси Nginx, балансировку, а иногда и миграцию на новый сервер.

И ещё момент. Если вы используете панель типа ISPmanager, Plesk или cPanel, настройки OPcache могут лежать в разных местах. Где-то это отдельный ini-файл, где-то — шаблон PHP handler. На практике я всегда рекомендую сначала найти, какой именно php.ini активен для FPM, потом уже править параметры. Иначе можно часами менять «не тот» файл и думать, что PHP издевается.

OPcache для WordPress, Bitrix и Laravel

У разных CMS одна и та же технология даёт немного разный эффект. WordPress обычно благодарнее всего реагирует на OPcache в паре с объектным кешем и хорошим хостингом. Bitrix любит аккуратную память и стабильный FPM. Laravel выигрывает от правильной автозагрузки, кеша конфигурации и роутов.

На WordPress я часто вижу такой сценарий: включили OPcache, поставили Redis, вычистили мусорные плагины — и PageSpeed на мобильном растёт с 35–45 до 70+ без шаманства. Если ещё добить ускорение WordPress, отключить тяжёлые слайдеры и настроить картинки, результат становится заметным почти сразу. Но, честно говоря, если тема кривая и плагинов 40 штук, никакой OPcache не спасёт полностью.

В Bitrix всё чуть жёстче. Там я всегда смотрю на кеш компонента, управляемый кеш, композит и OPcache вместе. Отдельно OPcache даёт ускорение, но основная магия начинается, когда всё это работает как система. Если интересно, у меня есть отдельный разбор по Redis для сайта и по кешированию в Битрикс.

Laravel тоже любит OPcache, особенно если приложение большое. У меня был проект на Laravel 10 с PHP 8.2, где после нормальной настройки OPcache и перехода на production config мы сократили средний TTFB с 280 мс до 120–140 мс на типовых страницах. И это без переписывания контроллеров. Просто убрали лишнюю работу PHP.

Типичные ошибки при настройке OPcache

Самая частая ошибка — включить OPcache и больше ничего не делать. Это плохая идея. Ещё хуже — включить его, а потом забыть про деплой, логи и объём памяти. На сайте вроде бы всё работает, но при обновлении внезапно остаются старые шаблоны, а разработчик бегает с криком «у меня на сервере не обновилось».

Вторая ошибка — слишком маленький кеш. Я уже говорил про это, но повторю: 64 MB для большого сайта — это часто смешно. Сайт начинает компилировать одни и те же файлы заново, и смысл теряется. Третья ошибка — бездумное отключение validate_timestamps в проектах, которые обновляются вручную. Так делать нельзя, если у вас нет дисциплины деплоя.

Четвёртая ошибка — игнорировать серверные ограничения. Иногда проблема не в OPcache, а в том, что хостинг режет память, FPM стартует в урезанном режиме, MySQL душит запросы, а сам сервер старый. В таком случае надо смотреть на инфраструктуру в целом. Я для начала советую пройтись по чек-листу выбора хостинга, а потом уже крутить PHP.

<?php
// Быстрая проверка статуса OPcache в PHP
$status = opcache_get_status(false);

echo '<pre>';
print_r([
    'enabled' => $status['opcache_enabled'] ?? null,
    'memory_usage' => $status['memory_usage'] ?? null,
    'interned_strings_usage' => $status['interned_strings_usage'] ?? null,
    'opcache_statistics' => $status['opcache_statistics'] ?? null,
]);
echo '</pre>';

Этот кусок я иногда даю даже владельцам сайтов, которые не лезут в сервер руками. Он помогает хотя бы понять, включён ли OPcache, сколько памяти занято и не переполнен ли кеш. Если статус не читает данные, часто проблема в правах, конфигурации или отключённой функции в php.ini.

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

Проверка — это не просто открыть phpinfo и успокоиться. Я обычно смотрю на несколько признаков. Во-первых, реально ли включён кеш. Во-вторых, не растёт ли количество missed hits слишком быстро. В-третьих, как ведёт себя сайт после деплоя и после перезапуска PHP-FPM.

Из инструментов я часто использую phpinfo, opcache_get_status(), логи FPM и мониторинг по CPU/RAM. Если у клиента есть Uptime-мониторинг и метрики в Grafana или хотя бы в панели хостинга, это уже хорошо. Подробно про наблюдение за доступностью я писал в статье настройка uptime-мониторинга сайта.

Ещё один рабочий способ — сравнить нагрузку до и после. На одном магазине с PHP 8.3 и MySQL 8.0 после включения OPcache и перенастройки FPM число запросов, которые сервер выдерживал без деградации, выросло почти в полтора раза. Это не магия. Просто PHP перестал заново переваривать одни и те же файлы на каждом хите.

Когда OPcache не спасает и нужны другие улучшения

И вот тут надо быть честным. OPcache — это ускоритель PHP, но не универсальный спасатель. Если сайт грузит 20 мегабайт изображений, тянет 15 внешних скриптов, делает по 30 SQL-запросов на страницу и крутится на дешёвом shared-хостинге, один OPcache проблему не закроет.

В таких случаях я всегда иду по цепочке. Сначала базовая диагностика. Потом кеширование. Потом база. Потом фронтенд. Потом сервер. Иногда ещё и архитектура. Если проект вырос, а внутри технический долг — это уже отдельная история, и честно говоря, её надо решать, а не маскировать кешем. У меня про это есть материал технический долг сайта: что это и как бороться.

Для сайтов на WordPress очень полезно сочетать OPcache с lazy loading изображений, WebP/AVIF и нормальным кешем статики. Для проектов на Bitrix и Laravel часто нужна ещё и оптимизация SQL. Если база тормозит, PHP будет ждать. Тут уже надо смотреть оптимизацию базы данных MySQL и иногда даже индексы, планы запросов и тяжёлые выборки.

По опыту, лучший результат даёт не одна настройка, а связка из нескольких решений. OPcache — это фундамент. Но если фундамент стоит на кривой плите, дом всё равно перекосится.

Мои рекомендации на 2026 год

Если коротко, в 2026 году я бы смотрел на OPcache как на обязательный элемент базовой производительности PHP. Для новых проектов на PHP 8.2 и 8.3 он должен быть включён сразу. Для старых сайтов на PHP 8.1 — тоже, но с проверкой совместимости и нагрузочного теста. Без этого лезть в прод — так себе затея.

Для большинства сайтов я бы стартовал с таких значений: 128 MB памяти, 16 MB interned strings, 100000 файлов, timestamps выключены на проде только при нормальном деплое, а после релиза — обязательная проверка статуса кеша. Если проект крупный, можно поднять память до 256 MB. Если маленький — иногда и 64 MB хватает, но я бы всё равно оставлял запас.

И ещё. Не забывайте, что OPcache — часть общей системы. Сайт должен жить на нормальном хостинге, с актуальным PHP, хорошей БД, адекватным кешем и безопасной конфигурацией. Если у вас всё это не настроено, я бы начал с поддержки WordPress, поддержки Битрикс или общей доработки сайта, а потом уже тонко крутил OPcache. Иначе вы просто полируете отдельный винт в старом системнике, который давно пора апгрейдить.

На моей практике именно OPcache часто даёт тот самый «быстрый эффект», который видит клиент уже в день внедрения. Страница открывается бодрее, сервер перестаёт задыхаться под одинаковыми запросами, а разработчику проще дышать. И это, честно говоря, очень приятная оптимизация: без боли, без рисков для SEO и без необходимости переписывать половину проекта.