Каждый визит на сайт — это цепочка операций: браузер пользователя, сервер, код приложения и почти всегда запросы к базе данных. Пока посетителей мало, система справляется, но с ростом трафика база первой превращается в узкое место: страницы генерируются медленно, а в часы пик проект может просто «лечь». Кэширование решает проблему системно — готовые результаты работы хранятся в быстрой памяти и отдаются за миллисекунды, не трогая базу данных. В этой статье разберём три уровня кэша — серверный, Redis и CDN — и покажем, как их связка на практике ускоряет сайт в 3–5 раз.
Почему кэширование даёт такой прирост
Принцип прост: большинство запросов пользователей — это чтение одних и тех же данных. Каталог товаров, категории, блоки «популярное», тексты страниц меняются редко, а запрашиваются постоянно. Каждый раз собирать их заново — значит выполнять десятки SQL-запросов: типичный запрос к базе занимает 50–200 мс, а чтение из кэша в оперативной памяти — доли миллисекунды. Кэш превращает повторяющуюся дорогую работу в однократную: данные считаются один раз и переиспользуются тысячами посетителей. Именно поэтому кэширование — самый выгодный способ ускорить сайт без апгрейда серверов.
Серверный кэш: первый и самый дешёвый уровень
Полный кэш страниц (full-page cache) сохраняет готовый HTML-ответ и отдаёт его следующим посетителям напрямую из nginx, минуя PHP и базу данных. Страница, которая генерировалась 300–500 мс, начинает отдаваться за 2–5 мс. Дополнительно используются кэш фрагментов (отдельных блоков страницы) и OPcache — кэш скомпилированного кода PHP. Ограничение полного кэша страниц — персонализированный контент: корзина, имя пользователя, личные цены. Для таких зон применяют кэш фрагментов или подгрузку персональных блоков через AJAX поверх кэшированной страницы.
Redis: база данных, которая живёт в оперативной памяти
Redis — хранилище типа «ключ-значение», которое держит данные в RAM. Ответ приходит за 0,1–1 мс — на два порядка быстрее SQL-запроса с его дисковыми операциями. При этом Redis умеет сохранять данные на диск (персистентность), масштабироваться в кластер и работать как брокер очередей. Типичные сценарии: хранение сессий пользователей (позволяет балансировать нагрузку между несколькими серверами), кэш результатов тяжёлых запросов, счётчики просмотров, ограничение частоты запросов, очереди фоновых задач. Для интернет-магазина Redis — естественное место для корзины и фильтров каталога.
Что хранить в Redis, а что — нет
Отличные кандидаты на кэширование в Redis:
- Результаты тяжёлых запросов — топ товаров, меню категорий, агрегаты для отчётов;
- Сессии и корзины — мгновенный доступ и устойчивость к перезапускам основного сервера;
- Вычисляемые данные — цены со скидками, рейтинги, блоки рекомендаций;
- Счётчики и лимиты — просмотры карточек, защита от перебора паролей;
- Очереди задач — отправка писем, генерация PDF, выгрузки в CRM и 1С.
А вот финансовые транзакции и данные со строгой согласованностью (остатки на складе при оформлении заказа, списание средств) в кэше держать нельзя. Источник истины остаётся в основной базе — кэш лишь разгружает чтение, а не заменяет запись.
CDN: приближаем контент к пользователю
CDN — сеть серверов (узлов), распределённых по стране и миру. Статика — картинки, стили, скрипты, видео — кэшируется на узле рядом с пользователем и отдаётся за 20–50 мс вместо 150–300 мс с вашего сервера в другом регионе. Для проектов с аудиторией по всей России это заметно ускоряет загрузку страниц. Бонусы CDN: автоматическое сжатие и оптимизация изображений (WebP/AVIF), терминация TLS, базовая защита от DDoS-атак. Важно, что CDN кэширует не только статику: анонимные HTML-страницы — каталог и карточки товаров — можно отдавать с узлов, полностью сняв эту нагрузку с Origin-сервера.
Инвалидация: как не показать пользователю старую цену
Среди разработчиков есть шутка, что в computer science есть две по-настоящему сложные задачи, и инвалидация кэша — одна из них. Если данные изменились, а кэш не сброшен, покупатель увидит устаревшую цену — для e-commerce это хуже медленного сайта. Рабочие стратегии:
- TTL (время жизни) — каждая запись хранится, например, 5–15 минут. Просто и подходит данным, которым допустимо «задержаться».
- Сброс по событию — при изменении товара код удаляет связанные ключи: карточку, страницы каталога, меню. Точнее TTL, требует аккуратной реализации.
- Теги кэша и версии — записи группируются по тегам («products», «category-42»), и вся группа сбрасывается одной командой.
- Stale-while-revalidate — пользователь мгновенно получает «старый» кэш, пока фоном формируется новый.
На практике стратегии комбинируют: короткий TTL как страховка плюс точечная инвалидация по событиям изменения данных.
Что даёт связка на практике: пример из e-commerce
Интернет-магазин на 100–150 тыс. визитов в месяц. До оптимизации: TTFB (время до первого байта) — 850 мс, загрузка процессора базы данных в пик — 85%, любая рассылка или промо-акция укладывала сайт. Внедрили полный серверный кэш для каталога и карточек товаров, Redis для сессий, корзин и фильтров, CDN — для статики и анонимных страниц. Результат через месяц: TTFB — 110 мс, нагрузка на базу упала на 75%, проект выдерживает всплески трафика в 5–10 раз выше обычных. Дополнительный эффект: тот же сервер стал пропускать в разы больше посетителей — покупка более мощного железа отложилась минимум на год.
Как понять, что вашему проекту пора кэшировать
Проверьте по чек-листу:
- TTFB стабильно выше 500 мс (легко измерить через PageSpeed Insights или curl с параметром -w);
- загрузка CPU базы данных регулярно превышает 70–80%;
- в slow query log — тяжёлые повторяющиеся SELECT-запросы;
- сайт замедляется или падает на акциях и email-рассылках;
- расходы на хостинг растут быстрее трафика.
Совпали два и более пунктов — кэширование даст быстрый и измеримый эффект, часто ещё до любых доработок кода.
Вывод
Кэширование — это не «одна кнопка ускорения», а архитектурное решение из трёх уровней: серверный кэш закрывает повторяющиеся запросы страниц, Redis забирает данные приложения и сессии, CDN разгружает доставку статики и приближает контент к пользователю. Начинать стоит с измерения: TTFB, нагрузка на БД и slow query log покажут, где узкое место именно у вас. Порядок внедрения, как правило, следующий: сначала серверный кэш страниц, затем Redis, затем CDN. Если хотите такой же результат — наши разработчики проведут аудит производительности и внедрят кэширование с учётом специфики вашего проекта.