Page cache в WordPress ускоряет сайт за счёт выдачи готовой HTML-страницы вместо повторной сборки её на каждом запросе. Но если включить кэш без исключений, легко сломать то, что должно меняться для каждого пользователя: формы, корзину, личный кабинет, избранное, счётчики, персональные блоки и часть аналитики. Поэтому задача не просто «включить кэш», а настроить его так, чтобы статические страницы отдавались быстро, а динамика оставалась живой.
Если у вас обычный контентный сайт, page cache почти всегда можно использовать. Если это магазин, сайт с авторизацией или сервис с личным кабинетом, кэш тоже нужен, но его придётся настраивать аккуратнее: исключать отдельные URL, не кэшировать страницы для вошедших пользователей и проверять, какие элементы подгружаются через AJAX или серверный рендеринг.
Что именно кэшировать, а что оставлять динамическим
Page cache работает на уровне целой страницы. Это не объектный кэш и не кэш браузера. Он сохраняет результат генерации HTML и отдает его следующим посетителям, пока кэш не истечёт или не будет сброшен. Отсюда главное правило: кэшировать можно то, что одинаково для всех посетителей, а всё персональное и зависящее от состояния пользователя — исключать или выводить отдельно.
Обычно безопасно кэшируются:
- главная страница;
- страницы записей и страниц с одинаковым содержимым для всех;
- категории, теги, архивы;
- лендинги без персонализации;
- страницы справки, блога, портфолио.
Обычно нельзя кэшировать без исключений или нужно проверять отдельно:
- страницу корзины;
- оформление заказа;
- личный кабинет;
- страницы входа, регистрации и восстановления пароля;
- формы, которые показывают состояние после отправки;
- страницы с персональными рекомендациями, балансом, уведомлениями;
- любые страницы, где контент зависит от cookies, сессии или авторизации.
Если на странице есть и статический, и динамический контент, не обязательно отключать кэш целиком. Часто достаточно вынести динамический фрагмент в отдельную подгрузку через JavaScript или убедиться, что плагин кэширования не сохраняет пользовательское состояние в HTML.
Как включить page cache в WordPress
В WordPress page cache обычно включают через плагин кэширования или через серверный слой, если хостинг это поддерживает. Для большинства владельцев сайтов самый практичный путь — плагин: он проще в настройке и позволяет задать исключения без правок на сервере.
Перед включением сделайте резервную копию и, если сайт уже в работе, по возможности проверьте настройку на staging-копии. Это особенно важно для магазинов и сайтов с формами: неудачная конфигурация может привести к тому, что посетители увидят устаревшую корзину, чужое состояние входа или старые данные в личном кабинете.
Дальше общий порядок такой:
- Установите и активируйте плагин кэширования, который умеет page cache.
- Включите кэш страниц в настройках плагина.
- Проверьте, как плагин работает с мобильной версией, если у сайта отдельная мобильная тема или разные шаблоны.
- Настройте очистку кэша при обновлении контента.
- Добавьте исключения для динамических URL и страниц с пользовательским состоянием.
У разных плагинов названия пунктов отличаются, но логика одна и та же: включить генерацию и хранение HTML, затем ограничить кэш там, где он вреден.
Если хостинг поддерживает серверный кэш
На некоторых хостингах page cache уже есть на уровне nginx, LiteSpeed, Varnish или встроенного механизма панели. Это быстрее и надёжнее, чем чисто PHP-решение, но и требования к настройке выше. В таком случае сначала проверьте, не включён ли кэш у хостера по умолчанию, и не дублируется ли он плагином. Два слоя page cache одновременно не всегда проблема, но иногда они мешают друг другу при очистке и создают путаницу с устаревшими страницами.
Если у вас managed-хостинг, лучше следовать документации провайдера: у них часто есть свой способ исключать URL и очищать кэш. На обычном shared-хостинге чаще всего проще и безопаснее использовать плагин.
Какие страницы и разделы нужно исключить из кэша
Исключения — это не дополнительная опция, а обязательная часть настройки. Если их не сделать, кэш начнёт отдавать одинаковый HTML всем посетителям, а это и ломает динамику.
В первую очередь исключают:
- страницы входа, регистрации и восстановления пароля;
- личный кабинет и все его вложенные разделы;
- корзину, оформление заказа и страницы после оплаты;
- страницы с формами, если после отправки на них показывается персональный результат;
- страницы поиска, если результаты зависят от параметров запроса и должны обновляться сразу;
- страницы с временными сообщениями, уведомлениями, токенами или одноразовыми ссылками.
Если сайт на WordPress использует стандартные пути, обычно исключают URL вроде /wp-login.php, а также служебные страницы плагинов и темы, где отображается пользовательское состояние. Но не стоит слепо копировать чужой список исключений: ориентируйтесь на реальные разделы вашего сайта. На одном проекте достаточно исключить три страницы, на другом — десяток шаблонов и несколько параметров URL.
Отдельно проверьте страницы, где динамика завязана на cookies. Например, если посетитель выбирает город, язык, склад или способ доставки, а значение сохраняется в cookie, page cache может показать не тот вариант следующему пользователю. В таких случаях либо исключают страницу из кэша, либо настраивают отдельные кэш-версии по cookie, если плагин это поддерживает.
Как не сломать формы, корзину и личный кабинет
Формы обычно ломаются не сами по себе, а из-за того, что кэш отдаёт старую страницу с уже устаревшими nonce, токенами или состоянием после отправки. Если после отправки формы пользователь видит старое сообщение или форма перестаёт отправляться, сначала проверьте, кэшируется ли страница целиком. Для страниц с важной интерактивностью лучше отключить page cache полностью или перевести форму на отдельную страницу подтверждения.
С корзиной и личным кабинетом ситуация похожая, но риск выше: там нельзя показывать чужие данные. Для таких страниц правило простое — не кэшировать их HTML. Если часть интерфейса должна быть быстрой, а часть персональной, используйте отдельную подгрузку данных после загрузки страницы. Это уже задача темы, плагина магазина или кастомной разработки, но не page cache.
Проверьте ещё один момент: некоторые плагины кэширования умеют исключать страницы, но не умеют корректно обходить кэш для авторизованных пользователей. Если у вас есть вход в админку, редакторский кабинет или закрытый раздел, убедитесь, что для вошедших пользователей кэш не мешает видеть актуальные данные. Обычно такие страницы либо не кэшируются вовсе, либо кэшируются отдельно для разных ролей, но второй вариант требует аккуратной настройки и не всегда нужен.
Счётчики, аналитика и скрипты: что проверять отдельно
Счётчики посещаемости, пиксели, виджеты чатов и аналитика обычно работают через JavaScript и сами по себе не зависят от page cache. Но проблемы возникают, если скрипт вставлен в HTML так, что кэш сохраняет устаревший код, или если плагин оптимизации объединяет и откладывает скрипты без проверки.
После включения кэша проверьте:
- загружается ли код аналитики на всех нужных страницах;
- не дублируются ли события после очистки кэша;
- не пропадает ли виджет на страницах, где он должен быть виден;
- не меняется ли порядок загрузки скриптов так, что часть из них перестаёт работать.
Если счётчик вставлен через шаблон темы или хук WordPress, page cache обычно не мешает, потому что скрипт попадает в кэшированную HTML-страницу как есть. Но если вы меняете код счётчика и не видите обновления, сначала очистите кэш страницы и кэш плагина, а потом проверьте браузерный кэш и CDN, если он есть.
Как проверить, что кэш работает правильно
После настройки не ограничивайтесь открытием сайта в обычной вкладке. Нужно проверить и скорость, и корректность динамики.
Практический порядок проверки такой:
- Откройте страницу в режиме инкогнито и убедитесь, что она загружается без ошибок.
- Обновите её несколько раз и посмотрите, не меняется ли содержимое, которое должно быть одинаковым.
- Проверьте страницы, которые вы исключили из кэша: они должны показывать актуальное состояние после входа, добавления товара, отправки формы или смены параметра.
- Если используете плагин кэширования, посмотрите его статус: обычно он показывает, была ли страница отдана из кэша.
- Проверьте HTML-источник страницы и заголовки ответа, если умеете это делать: по ним видно, что страница действительно отдаётся как cached response.
Ещё полезно сравнить поведение для гостя и для авторизованного пользователя. Частая ошибка — всё выглядит нормально для администратора, но у обычного посетителя форма или корзина ведут себя иначе. Это связано с тем, что некоторые плагины по-разному обрабатывают кэш для вошедших и неавторизованных пользователей.
Когда кэш лучше не включать без доработки
Есть сайты, где page cache нельзя включать «в лоб». Это не значит, что ускорение невозможно, но сначала нужно привести в порядок архитектуру страниц.
Осторожность нужна, если у вас:
- много персонализированного контента на главной;
- динамические фильтры, завязанные на параметры URL и cookies;
- часто меняющиеся остатки, цены или статусы;
- сложная авторизация с несколькими ролями и закрытыми разделами;
- самописные формы и кабинеты без отдельной логики исключений.
В таких проектах сначала определяют, какие блоки можно кэшировать, а какие нужно вынести в отдельную подгрузку. Иногда достаточно исключить несколько URL. Иногда приходится дорабатывать тему или плагины, чтобы динамика не жила внутри одной и той же HTML-страницы с кэшем.
Если сомневаетесь, начните с малого: включите кэш только для публичных страниц, исключите все пользовательские разделы и проверьте сайт на реальных сценариях — вход, отправка формы, добавление в корзину, переход в кабинет, смена языка или города. Это быстрее, чем потом искать, почему у части посетителей отображается чужое состояние страницы.
Хорошо настроенный page cache в WordPress не мешает динамическому контенту, а разгружает сайт там, где это безопасно. Ключевой принцип простой: кэшируйте то, что одинаково для всех, и не пытайтесь ускорить через кэш то, что должно меняться от пользователя к пользователю. Тогда страницы будут открываться быстрее, а формы, корзина, личный кабинет и счётчики останутся рабочими.