Аннотация. Кеширование в WordPress нужно не ради красивого отчета Lighthouse, а ради стабильной первой загрузки, меньшей нагрузки на хостинг и более спокойной работы сайта во время рекламы. Но кеш легко настроить так, что сайт визуально быстрый, а заявки, корзина или редактор начинают вести себя странно.
Что кешировать в WordPress
В WordPress есть несколько уровней кеша: кеш страницы, объектный кеш, кеш браузера и кеш на уровне CDN. Для сайта услуг чаще всего достаточно кеша страниц, сжатия статики, правильных заголовков кеширования и аккуратной минификации CSS/JS.
Для интернет-магазина схема сложнее. Нельзя бездумно кешировать корзину, checkout, личный кабинет, страницы с nonce и динамические блоки пользователя. Иначе клиент видит устаревшую корзину, форма перестает проходить проверку или сообщение об отправке появляется не там, где нужно.
Пример 1 сайт услуг на WordPress
Есть лендинг с блоками услуг, кейсами, отзывами и Contact Form 7. Для него можно кешировать почти все публичные страницы: главную, блог, кейсы, страницы услуг. Но форму нужно проверить отдельно.
- Открываем страницу в инкогнито.
- Отправляем тестовую заявку.
- Проверяем письмо на почте.
- Сбрасываем кеш и повторяем отправку.
- Проверяем мобильную версию, потому что там чаще всплывают проблемы с сообщением формы.
Если после включения кеша форма стала “думать” бесконечно, кнопка белеет, сообщение появляется снизу или nonce устаревает, значит оптимизация затронула скрипты формы. В таком случае исключают JS Contact Form 7 из отложенной загрузки или делают исключение для блока заявки.
Пример 2 WooCommerce-магазин
В магазине кеш нужен, но он должен понимать, где статичная витрина, а где динамическая покупка. Категории, карточки товаров, SEO-страницы и блог можно ускорять агрессивнее. Корзину, оплату и личный кабинет лучше исключить.
Типовая ошибка: включить “кешировать всё” и потом удивляться, почему пользователь добавляет товар, а корзина не меняется. С технической стороны страница просто отдает старую HTML-версию. Для клиента это выглядит как поломка магазина.
Пример 3 сайт после редизайна
Часто после правки темы владелец видит старый дизайн, а разработчик уже загрузил новые файлы. Причина обычно в трех слоях кеша: браузер, плагин кеширования и opcache на сервере. Поэтому в теме желательно версионировать файлы CSS/JS. Например, после правки менять версию `20260802-1170`, чтобы браузер забрал новый файл.
Что чаще всего ломает кеш
- агрессивная минификация JS без проверки консоли;
- отложенная загрузка скриптов формы;
- кеширование страниц с личными данными;
- слишком долгий browser cache для CSS без версионирования;
- одновременное включение нескольких кеш-плагинов;
- lazy-load для LCP-картинки на первом экране.
Чек-лист после настройки
- главная открывается без горизонтального скролла;
- LCP-картинка не lazy-loaded;
- Contact Form 7 отправляет письмо;
- сообщение формы видно сверху блока;
- админка WordPress редактируется без JS-ошибок;
- корзина WooCommerce не кешируется;
- sitemap и robots.txt доступны;
- в Lighthouse есть LCP, а не NO_LCP.
Как я обычно настраиваю
Сначала включаю базовый кеш страниц и сжатие. Потом отдельно проверяю форму, меню, мобильную версию и админку. После этого уже можно аккуратно включать оптимизацию CSS/JS. Если сайт небольшой, лучше стабильные 90-95 баллов и рабочие заявки, чем “100”, но с поломанной формой.
Вывод A.S Groups
Кеш должен ускорять сайт, а не превращаться в черный ящик. Хорошая настройка выглядит спокойно: быстро открывается первый экран, формы работают, редактор WordPress не ломается, а после правок достаточно сбросить кеш и увидеть результат.
Сравнение подходов
Вывод из документации WordPress: кеширование ускоряет сайт, но его нужно применять с пониманием динамических частей страницы.
Рабочий пример настройки для сайта услуг
Представим сайт веб разработчика или небольшой студии. На главной есть первый экран, блок услуг, кейсы, отзывы, FAQ и форма заявки. Самый частый сценарий посетителя простой. Человек открывает сайт с телефона, быстро смотрит доверие и жмет кнопку обсуждения проекта. Если в этот момент страница тяжелая или форма работает нестабильно, рекламный трафик начинает сливаться.
В такой ситуации кеш должен помогать именно первому экрану и статичным блокам. Логотип, обложка, стили и изображения должны приходить быстро. А форма, сообщение об отправке и скрипты проверки должны оставаться живыми. Поэтому я не советую сразу включать все ускорители. Сначала нужно понять, какие элементы на странице статичные, а какие зависят от пользователя.
Как я бы проверял такой сайт
Сначала открывается главная страница в обычном браузере и в инкогнито. Потом проверяется мобильная версия, потому что именно там чаще всего видны скачки, лишний горизонтальный скролл и проблемы с первым экраном. После этого отправляется тестовая заявка. Если письмо пришло, сообщение показалось в правильном месте и кнопка вернулась в нормальное состояние, можно двигаться дальше.
Следующий шаг это проверка после очистки кеша. Многие ошибки проявляются не при первой загрузке, а после обновления CSS или JavaScript. Например, владелец сайта видит старую версию кнопок, а новый посетитель уже видит новую. Такое поведение часто связано с browser cache и отсутствием версии у файлов темы.
Нормальный результат
Нормальная настройка кеша не должна требовать постоянного ручного ремонта. После изменения темы достаточно обновить версию файлов, очистить кеш и проверить пару ключевых страниц. Если каждое изменение превращается в поиск старого CSS, значит кеш настроен слишком непрозрачно.
Что важно для владельца сайта
Владелец сайта обычно смотрит на цифры скорости, но бизнесу важнее стабильность заявок. Быстрый сайт без рабочих форм не решает задачу. Поэтому после любой оптимизации нужно проверять не только Lighthouse, но и реальный путь клиента. Открыл страницу, прочитал, нажал кнопку, отправил форму, получил ответ.
Если сайт используется для рекламы, проверку нужно повторять перед запуском кампании. Иногда маленькая правка в оптимизации переносит скрипт формы вниз, меняет порядок загрузки или ломает сообщение. На глаз сайт выглядит нормально, но заявка не уходит. Это неприятная ошибка, потому что она не всегда видна сразу.
WordPress Developer Resources Caching web.dev Largest Contentful Paint