Кеширование WordPress: ошибки новичков и как их обойти

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

Что нужно иметь до начала

• WordPress 6.x, доступ в админку с правами администратора;
• доступ к файлам сайта — по SFTP или через файловый менеджер панели хостинга. Понадобится правка wp-config.php и, на Apache, .htaccess;
• знание, какой веб-сервер у вас на хостинге: Apache, LiteSpeed или Nginx. Это определяет и выбор плагина, и то, будет ли работать .htaccess;
• свежая резервная копия файлов и базы. Кеширование ломает сайт редко, но ломает заметно — и чинится быстрее откатом, чем разбором;
• браузер с панелью разработчика или консоль с curl — без проверки заголовков вы не узнаете, работает кеш или просто установлен.

Если сайт на LiteSpeed или OpenLiteSpeed, вам почти наверняка нужен LiteSpeed Cache: он использует кеш на уровне сервера, а не PHP. На Apache берите WP Super Cache или W3 Total Cache. На Nginx без root-доступа проще всего начать с Cache Enabler или того же WP Super Cache в режиме записи файлов.

Порядок действий

1. Замерьте, что есть сейчас. Откройте главную в режиме инкогнито и посмотрите в панели разработчика на вкладке Network время ответа первого запроса (документа). Запишите это число. Повторите для самой тяжёлой страницы — каталога или архива. Проверка: у вас на руках два числа до настройки, иначе сравнивать будет нечего.
2. Отключите все остальные плагины кеширования. Зайдите в «Плагины» и деактивируйте всё, что кеширует страницы: второй кеш-плагин, старый «оптимизатор», модуль кеша в составе SEO-набора. Проверка: в списке активных плагинов осталось ноль плагинов кеширования страниц.
3. Установите один плагин и включите кеш страниц. В WP Super Cache это вкладка Easy и переключатель кеширования; в W3 Total Cache — General Settings, блок Page Cache; в LiteSpeed Cache — раздел Cache. Сохраните. Проверка: плагин не показывает красных предупреждений о конфликте или о правах на запись.
4. Убедитесь, что WordPress знает про кеш. Многие плагины дописывают строку в wp-config.php сами, но не всегда. Откройте файл и проверьте, что строка есть и стоит выше подключения wp-settings.php.
5. Задайте исключения. Из кеша нужно исключить страницы корзины, оформления заказа, личного кабинета и всё, где содержимое зависит от пользователя. В настройках плагина есть поле для URL или путей, не подлежащих кешированию. Для WooCommerce это как минимум /cart/, /checkout/, /my-account/ — или их русские аналоги, если постоянные ссылки переведены. Проверка: положите товар в корзину в инкогнито, перезагрузите страницу корзины — товар на месте.
6. Отключите кеш для залогиненных. Эта опция есть во всех перечисленных плагинах и по умолчанию обычно включена в нужную сторону — проверьте, что кеш не отдаётся авторизованным пользователям. Проверка: зайдите под админом, откройте любую запись, в исходном коде страницы нет пометки о кешировании.
7. Добавьте кеш браузера для статики. На Apache — через mod_expires в .htaccess (код ниже). На LiteSpeed и Nginx это настраивается плагином или конфигом сервера, .htaccess там либо игнорируется, либо обрабатывается иначе. Проверка: в ответе на запрос CSS-файла появились заголовки Cache-Control и Expires со сроком в месяцах, а не в секундах.
8. Сбросьте кеш и прогрейте сайт. Нажмите «Очистить кеш», затем откройте 5–10 ключевых страниц в инкогнито по два раза. Второе открытие должно быть заметно быстрее. Проверка: время ответа документа упало относительно числа из первого шага — обычно в разы, если раньше кеша не было вовсе.

Строка в wp-config.php

// wp-config.php, WordPress 6.x
// Строка должна стоять ВЫШЕ подключения wp-settings.php
define('WP_CACHE', true);

/* That's all, stop editing! Happy publishing. */
require_once ABSPATH . 'wp-settings.php';

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

Кеш браузера на Apache

# .htaccess, Apache 2.4 с подключённым mod_expires
# Блок добавляйте ДО секции # BEGIN WordPress
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

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

Что включать и с какими значениями

Две строки с «выключено на первом проходе» — не осторожность ради осторожности. Минификация и перенос скриптов в конец страницы ломают вёрстку и слайдеры чаще, чем всё остальное вместе. Включайте их по одной галочке за раз, после того как базовый кеш уже работает и проверен.

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

Если не получилось

Белый экран или ошибка 500 после правки .htaccess

Сервер не понял директиву или на нём нет mod_expires. Удалите добавленный блок, сохраните файл, обновите страницу — сайт вернётся. Дальше либо уточните у хостинга, подключён ли модуль, либо настройте кеш браузера через опцию плагина.

В логах или на экране — Permission denied при записи в wp-content/cache

У PHP нет прав на запись в каталог кеша. Плагин при этом может показывать, что кеш включён, но файлы не появляются. Решается правами на каталог wp-content/cache на стороне хостинга — напишите в поддержку, формулировка простая: «PHP не может создавать файлы в wp-content/cache».

Посетитель видит чужую корзину или чужое имя в меню

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

Изменения на сайте не видны

Порядок проверки: очистить кеш плагина, затем кеш CDN, затем кеш браузера (жёсткая перезагрузка). Если после всего этого старая версия осталась — почти наверняка HTML отдаётся с длинным сроком жизни в браузере. Вернитесь к строке ExpiresByType text/html и поставьте 0 секунд.

Плагин жалуется на другой активный плагин кеширования

Два кеша страниц одновременно — это не двойная скорость, а конфликт за один и тот же каталог и за одни и те же правила в .htaccess. Оставьте один. Удаляя второй, проверьте, что он убрал за собой свои строки в .htaccess и wp-config.php.

Формы перестали отправляться, корзина пустеет

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

Что делать дальше

Через сутки работы кеша посмотрите в панели хостинга на нагрузку по CPU — если кеш встал правильно, она падает заметнее, чем время ответа. Затем по одной включайте оптимизации: сначала минификацию CSS, проверяя вёрстку на главной, в каталоге и на мобильном; потом JS. Отдельно стоит узнать у хостинга, есть ли Redis или Memcached: кеш объектов помогает там, где кеш страниц бессилен — в админке и на страницах корзины. Инвалидация кеша при сложных зависимостях между страницами и настройка CDN — отдельные темы, здесь мы включали базовый кеш и ставили защиту от самых частых поломок.

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

Кеш объектов — хранилище результатов отдельных запросов к базе (Redis, Memcached). Работает и на тех страницах, которые нельзя кешировать целиком, потому что ускоряет генерацию, а не заменяет её.

TTFB (time to first byte) — время от отправки запроса до первого байта ответа. Именно его вы видите как время загрузки документа в панели разработчика и именно он падает от кеша страниц.