Cloudflare для WooCommerce: как настроить кэш без поломки корзины и checkout

Cloudflare хорошо ускоряет статику WooCommerce уже «из коробки»: изображения, CSS и JavaScript подходят для edge cache. Но HTML каталога, карточек товаров и других динамических страниц по умолчанию обычно не кэшируется как обычный статический файл. Чтобы получить full-page cache на edge, используют Cloudflare Cache Rules — и именно здесь чаще всего появляется риск закэшировать персональную корзину или checkout.

Безопасная настройка строится не по принципу «Cache Everything для всего домена», а по принципу кэшировать только публичный контент и явно исключить всё, что зависит от сессии покупателя.

Ниже — схема, которую можно применить к обычному WooCommerce-магазину, а затем проверить по заголовкам Cloudflare и реальным сценариям покупки.

Почему обычный CDN-кэш недостаточен для WooCommerce

По официальной документации Cloudflare статические ресурсы кэшируются по умолчанию, а динамический HTML — нет. Cache Rules позволяют изменить eligibility и управлять TTL для совпавших запросов. Это полезно для публичных страниц каталога, но опасно для страниц, где контент зависит от cookies, сессии или пользователя.

WooCommerce, в свою очередь, хранит состояние покупателя в cookies и серверной сессии. Поэтому две визуально одинаковые страницы могут фактически содержать разные данные: количество товаров, выбранную валюту, персональные цены, уведомления или результат входа в аккаунт.

Если edge отдаст HTML одного клиента другому, проблема будет уже не в скорости, а в корректности магазина.

Какие страницы WooCommerce нельзя кэшировать как общий HTML

Минимальный набор динамических маршрутов:

• Cart — корзина и её содержимое;
• Checkout — оформление, доставка, платежи, nonce и итоговые суммы;
• My Account — данные авторизованного пользователя;
• страницы order-pay, order-received и другие endpoint-сценарии заказа;
• любые кастомные страницы, где вывод зависит от сессии, роли, геолокации или персональной цены.

WooCommerce отдельно рекомендует исключать Cart и Checkout из page cache, поскольку это динамический session-specific контент. Если URL магазина переведены или изменены, нельзя слепо копировать /cart/ и /checkout/: сначала проверьте реальные endpoints в текущей конфигурации.

Cookies, которые должны выключать общий page cache

Даже публичная карточка товара может стать персонализированной после того, как покупатель положил товар в корзину. Для этого WooCommerce использует cookies, в том числе:

• woocommerce_items_in_cart;
• woocommerce_cart_hash;
• wp_woocommerce_session_*;
• другие cookies расширений, если они меняют HTML для конкретного клиента.

Cloudflare поддерживает Cache Rule с условием по http.cookie и действием Bypass cache. В официальном примере Cloudflare такой подход используется для исключения запросов по наличию определённой cookie.

(http.cookie contains "woocommerce_items_in_cart") or
(http.cookie contains "wp_woocommerce_session_")

Это пример логики, а не универсальная готовая формула. На реальном сайте список расширяется, если магазин использует мультивалютность, B2B-роли, персональные скидки, геолокацию, membership или другие плагины, меняющие выдачу.

Практическая схема Cache Rules

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

Правило 1: разрешить edge cache только там, где это безопасно

Не обязательно делать весь домен eligible. Чем уже условие, тем проще контролировать последствия. Например, можно начать с публичных категорий и карточек товаров для анонимных пользователей, а затем расширять охват после проверки.

Cloudflare предупреждает: при выборе Eligible for cache и особенно при принудительном Edge TTL нужно понимать поведение origin headers. Не стоит игнорировать Cache-Control только ради высокого HIT-rate, пока не проверены cookies и персонализация.

Правило 2: bypass для системных URL

Для Cart, Checkout и My Account создайте отдельное правило Bypass cache. Пример концептуального выражения:

(http.request.uri.path starts_with "/cart") or
(http.request.uri.path starts_with "/checkout") or
(http.request.uri.path starts_with "/my-account")

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

Правило 3: bypass по session cookies

Отдельное правило по WooCommerce cookies защищает публичные URL после того, как пользователь уже начал взаимодействовать с магазином. Это важно, потому что URL товара не меняется, а состояние покупателя — меняется.

Порядок правил в Cloudflare важен

Cache Rules stackable: несколько правил могут совпасть с одним запросом. Если они задают конфликтующее значение одной настройки, Cloudflare применяет значение из последнего совпавшего правила.

Поэтому опасная конфигурация выглядит так: сначала Bypass для checkout, а ниже — слишком широкое «Eligible for cache» для всего hostname. Последнее правило может переопределить cache eligibility.

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

Почему Set-Cookie требует особой осторожности

Cloudflare по-разному обрабатывает ответы с Set-Cookie в зависимости от cache eligibility, Origin Cache Control и Edge TTL. Особенно опасно принудительно игнорировать origin cache-control и задавать Edge TTL: в некоторых режимах Cloudflare может удалить Set-Cookie и закэшировать ответ.

Поэтому для WooCommerce не стоит начинать настройку с агрессивного «ignore cache-control». Сначала убедитесь, что публичный ответ действительно безопасен для общего кэша и не устанавливает session-specific cookie.

Как проверить, что Cloudflare реально кэширует нужные страницы

После публикации правил проверяйте не только визуальную скорость, но и response headers. Главный маркер — CF-Cache-Status.

• MISS — объект eligible, но в этом edge-кэше его ещё не было;
• HIT — ответ получен из edge cache;
• DYNAMIC — запрос не был eligible для cache;
• BYPASS — запрос был eligible, но ответ или настройки заставили Cloudflare не кэшировать его.

После purge первый запрос закономерно может быть MISS, а следующий — HIT. Не делайте вывод по одному запросу.

Чек-лист тестирования после включения Cache Rules

Cloudflare не заменяет object cache WooCommerce

Edge page cache и серверный object cache решают разные задачи. Cloudflare может не отправлять часть публичных запросов на origin вообще. Redis Object Cache уменьшает работу PHP и базы данных уже на сервере, когда запрос до WordPress всё-таки дошёл.

Для нагруженного магазина эти уровни хорошо дополняют друг друга. Практическая настройка Redis описана отдельно в статье Redis Object Cache для WooCommerce.

Если проблема связана с постоянными обновлениями мини-корзины, отдельно проверьте оптимизацию WooCommerce Cart Fragments. А общую логику page cache без поломки динамических форм можно сравнить с материалом про безопасный кэш WordPress.

Когда нужен аудит вместо ещё одного cache rule

Если TTFB высокий даже при bypass, checkout тормозит, а админка медленная, проблема может быть не в Cloudflare: медленные SQL-запросы, внешний API, Action Scheduler, PHP-FPM, плагины доставки или оплаты продолжают работать на origin.

В таком случае сначала измеряют серверную часть, а потом решают, какие страницы выгодно отдавать с edge. A.S Groups может выполнить доработку и технический аудит WooCommerce: проверить Cache Rules, PHP/DB, AJAX, checkout и интеграции без отключения критических функций магазина.

Официальные документы для проверки настройки

• Cloudflare Cache Rules — eligibility, TTL и условия правил;
• Cloudflare: Bypass Cache on Cookie — официальный пример условия по cookie;
• Cloudflare cache responses — значения HIT, MISS, BYPASS и DYNAMIC;
• WooCommerce documentation — напоминание исключать Cart и Checkout из cache как динамические страницы.

Итог

Безопасный Cloudflare cache для WooCommerce строится вокруг разделения публичного и персонального контента. Публичные страницы можно постепенно делать eligible для edge cache, а Cart, Checkout, My Account и запросы с WooCommerce session cookies должны оставаться динамическими.

После каждой правки правил важны три проверки: порядок Cache Rules, фактический CF-Cache-Status и полный сценарий покупки от карточки товара до успешного заказа. Только после этого высокий HIT-rate действительно означает ускорение, а не скрытую ошибку магазина.