TTFB (Time To First Byte) — время от запроса страницы до получения первого байта ответа от сервера. Для обычного сайта на статике это доли секунды, но для интернет-магазина на WooCommerce TTFB часто улетает за 1–2 секунды, потому что каждая страница требует десятков запросов к базе данных ещё до того, как браузер получит первый байт HTML. Это напрямую бьёт по конверсии и входит в факторы ранжирования через Core Web Vitals.
WooCommerce — это надстройка над WordPress, где товар не простая запись, а сложная структура из основной записи, десятков мета-полей (цена, остаток, атрибуты, изображения галереи) и связанных таксономий. На каждый рендер страницы каталога или карточки товара WordPress выполняет множество отдельных SQL-запросов к wp_postmeta, если запросы не объединены в батч. Дополнительно WooCommerce постоянно работает с сессиями и корзиной пользователя, что усложняет кэширование страниц целиком — эти данные персональны для каждого посетителя.
Важно не путать два уровня кэширования. Page Cache (например, через Nginx fastcgi_cache или плагин типа WP Super Cache) сохраняет готовый HTML страницы целиком и отдаёт его без обращения к PHP вообще — быстро, но не подходит для страниц с персональным контентом (корзина, личный кабинет, checkout), их приходится исключать из кэша по URL-маске. Object Cache — это кэш на уровне отдельных данных внутри PHP (результаты SQL-запросов, вычисленные значения опций), который работает даже на персонализированных страницах, потому что кэширует не HTML целиком, а конкретные куски данных, повторно используемые между запросами.
По умолчанию WordPress использует Object Cache только в рамках одного запроса — кэш сбрасывается на каждой новой загрузке страницы. Подключение Redis через плагин Redis Object Cache делает этот кэш персистентным между запросами и между разными пользователями: результат тяжёлого запроса, посчитанный для одного посетителя, переиспользуется для следующего, пока данные не изменились. Конфигурация в wp-config.php:
define('WP_REDIS_HOST', '127.0.0.1'); define('WP_REDIS_PORT', 6379); define('WP_CACHE', true);
После подключения обязательно проверяю через админку статус «Connected» и слежу за hit rate в статистике плагина — низкий процент попаданий в кэш означает, что конфигурация неоптимальна или сайт активно инвалидирует кэш чаще, чем переиспользует его.
Redis снимает нагрузку с базы данных, но узким местом может остаться сам PHP-FPM, если пул воркеров настроен на дефолтных значениях хостинга. Для магазина со стабильным трафиком настраиваю pm = dynamic с подобранным под реальную нагрузку pm.max_children, чтобы не упираться в очередь запросов в пиковые часы, и включаю OPcache с достаточным opcache.memory_consumption, чтобы скомпилированный байт-код PHP не пересобирался на каждый запрос. На уровне Nginx для гостевых, не персонализированных страниц (главная, каталог без фильтров) настраиваю fastcgi_cache с коротким TTL и явным исключением URL корзины, оформления заказа и личного кабинета через fastcgi_cache_bypass.
Любая оптимизация без замера до и после — это вера, а не инженерия. Использую curl -o /dev/null -s -w "TTFB: %{time_starttransfer}n" для прямого измерения времени ответа сервера без учёта загрузки браузером статики, и WebPageTest для комплексной картины с учётом сети. На реальных проектах связка Redis Object Cache плюс тюнинг PHP-FPM обычно снижает TTFB карточки товара WooCommerce с 800–1200 мс до 150–250 мс — разница, ощутимая и пользователем, и алгоритмом ранжирования.
Кэширование страницы корзины или оформления заказа наравне с обычными страницами каталога — грубая, но нередкая ошибка при поверхностной настройке Page Cache. Если правила fastcgi_cache_bypass не исключают явно URL корзины, чекаута и личного кабинета, один посетитель может увидеть содержимое корзины другого пользователя, закэшированное на уровне сервера, — это не просто баг, а прямая утечка персональных данных между сессиями.
Вторая ошибка — включение Object Cache без последующей проверки hit rate. Redis может быть подключён технически корректно, но если TTL кэша выставлен слишком коротким или плагины сайта агрессивно инвалидируют кэш при каждом действии (что типично для некоторых конструкторов страниц), процент реальных попаданий в кэш остаётся низким, а нагрузка на Redis добавляется поверх нагрузки на MySQL, вместо того чтобы её заменять.
Третья — рост потребления памяти Redis без лимита и политики вытеснения. Без настроенного maxmemory и maxmemory-policy (обычно allkeys-lru) Redis может неограниченно расти в памяти сервера, пока не упрётся в системный OOM killer и не завершится аварийно вместе с частью сайта, которая на него полагается — параметры лимита памяти нужно выставлять сразу при внедрении, а не постфактум после первого инцидента.
Четвёртая — игнорирование измерений в реальных условиях. Замер TTFB с сервера, на котором стоит сайт, через localhost, не учитывает сетевую задержку до реального пользователя и может создавать ложное ощущение, что оптимизация уже достаточна — измерения стоит делать с внешней точки, желательно из региона основной аудитории магазина.
