Оптимистичный кэш: настройка для снижения TTFB

16 октября 2026 · Команда SaitHub · SEO-блог SaitHub

Что такое оптимистичный кэш и почему он важен

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

В контексте TTFB (Time to First Byte) этот механизм критически важен. Если запрос уходит в MySQL и ждёт ответа 500 мс, а кэш отдаёт страницу за 10 мс, пользователь воспринимает сайт как быстрый.

TTFB — время от отправки запроса до получения первого байта ответа. Норма для корпоративных сайтов — до 200 мс.
Stale-while-revalidate — директива кэширования, позволяющая отдавать устаревший ресурс и обновлять его в фоне.
ESI (Edge Side Includes) — технология вставки динамических блоков в статический кэш, чтобы не инвалидировать всю страницу.

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

Обычные решения вроде Memcached или Redis кэшируют результат запроса к базе данных. Если TTL (время жизни) истекло, кэш пуст, и запрос уходит в бэкенд. В моменты пиковой нагрузки, например во время распродажи, это приводит к каскадному отказу: тысячи одновременных запросов идут в БД, она не выдерживает нагрузку, и TTFB растёт до нескольких секунд.

Оптимистичный подход решает эту проблему. Кэш хранит данные и после истечения TTL. Он помечает их как «стале» (устаревшие), но продолжает отдавать. Одновременно фоновый воркер делает один запрос в БД для обновления. Остальные тысячи пользователей получают старый, но рабочий контент.

Это снижает нагрузку на базу данных на 90-95% в пиковые моменты. Вместо того чтобы БД обрабатывала 10 000 запросов в секунду, она обрабатывает один.

Настройка Varnish для работы со стале-кэшем

Varnish — популярный HTTP-кашер, который идеально подходит для реализации этой стратегии. Для включения оптимистичного поведения нужно отредактировать конфигурационный файл.

Базовый параметр stale-if-error указывает, что при ошибке соединения с бэкендом отдавать устаревший кэш. Параметр stale-while-revalidate задаёт время, в течение которого устаревший кэш считается валидным для фонового обновления.

stale-if-error — флаг, разрешающий отдачу кэша при недоступности бэкенда.
stale-while-revalidate — интервал (в секундах), в течение которого можно отдавать устаревший кэш.
max-stale — максимальное время хранения устаревших данных после отключения сервера.

Роль CDN и географическое распределение

Для глобального бизнеса оптимистичный кэш должен работать на уровне CDN. Серверы в разных регионах кэшируют контент ближе к пользователю. Если бэкенд в Москве, а пользователь в Сочи, задержка сети сама по себе увеличивает TTFB.

CDN с поддержкой ESI позволяет кэшировать 80% страницы (шрифты, картинки, статический HTML) и обновлять только 20% (личные данные, корзины). Это снижает время отдачи до 50 мс даже при медленном соединении с основным сервером.

Настройка DNS-записей и TTL на уровне CDN должна согласовываться с настройками Varnish. Если CDN кэширует страницу на 24 часа, а Varnish на 10 минут, возникает рассинхронизация. Лучше выстроить иерархию: CDN кэширует статику надолго, Varnish кэширует динамические блоки коротко.

Мониторинг и контроль качества данных

Главный риск оптимистичного кэша — пользователь видит старые цены или остатки товара. Это допустимо для каталогов, но недопустимо для личного кабинета или платежей.

Для мониторинга нужно отслеживать долю запросов, которые обслуживаются из стале-кэша. Если этот показатель превышает 10% в рабочее время, значит, бэкенд не справляется с обновлением.

Hit-ratio — доля запросов, удовлетворённых из кэша. Целевое значение — 95% и выше.
Stale-hit-ratio — доля запросов, удовлетворённых из устаревшего кэша. Должна быть меньше 5%.
Background-refresh-time — время, за которое фоновый процесс обновляет кэш. Должно быть меньше 100 мс.

Типичные ошибки при внедрении

Частая ошибка — кэширование авторизованных страниц. Если пользователь видит данные другого клиента из-за старого кэша, это инцидент безопасности. Необходимо четко отделять публичный контент от приватного.

Вторая ошибка — игнорирование заголовков Cache-Control. Если приложение отсылает no-cache, Varnish не будет кэшировать страницу, и оптимистичная логика не сработает.

Третья ошибка — отсутствие механизма инвалидации. При изменении цены товара нужно отправлять сигнал кэшу на очистку соответствующих ключей. Без этого пользователь будет видеть старую цену до истечения TTL.