Кэш

Кэш — временное хранилище данных, которое сохраняет готовые копии страниц, запросов к базе данных и статических ресурсов для быстрой выдачи при повторных обращениях без повторной обработки. Применяется на всех уровнях веб-инфраструктуры: в браузере пользователя, на сервере сайта и в CDN-сетях доставки контента.

Что такое кэш

Кэш работает по принципу «сохрани один раз — отдавай быстро». Когда пользователь впервые заходит на страницу, сервер генерирует её полностью: делает запросы к базе данных, выполняет PHP или Python-код, формирует итоговый HTML. Все эти операции требуют ресурсов процессора и оперативной памяти и занимают от 200 мс до нескольких секунд. При следующем запросе той же страницы — от этого же пользователя или любого другого — сервер просто отдаёт готовую копию из кэша, минуя всю цепочку обработки. Для статичного контента время ответа сокращается с сотен миллисекунд до 5-20 мс. Для высоконагруженных проектов разница между работой с кэшем и без него — это разница между стабильным сайтом и регулярными падениями под пиковой нагрузкой.

Концепция кэширования появилась ещё в 1960-х годах в архитектуре процессоров, где кэш L1 и L2 хранил часто используемые инструкции ближе к ядру для ускорения вычислений. Для веба она стала актуальна с появлением протокола HTTP/1.1 в 1997 году — стандарт ввёл заголовки Cache-Control, Expires и ETag, которые по сей день управляют браузерным кэшированием. В 2000-х интернет-магазины с миллионами страниц столкнулись с проблемой: серверы не справлялись с нагрузкой в пиковые дни распродаж. Именно тогда в индустрии массово распространились решения серверного кэширования — Memcached появился в 2003 году, Redis — в 2009-м. Сегодня кэш встроен в любой серьёзный веб-стек: Varnish, Nginx FastCGI Cache, плагины WP Rocket и W3 Total Cache для WordPress, CDN-кэширование от Cloudflare и Akamai. Без понимания этой эволюции сложно выбрать правильный инструмент под конкретную задачу.

Для маркетолога кэш важен по двум причинам, напрямую влияющим на продажи и трафик. Первая — Core Web Vitals. Google с 2021 года официально использует скорость загрузки (показатели LCP, FID, CLS) как фактор ранжирования. Без кэширования сайт с динамическим контентом редко укладывается в порог LCP меньше 2.5 секунды, что прямо ударяет по позициям в поисковой выдаче. Вторая — конверсия. Amazon ещё в 2012 году посчитал, что каждые 100 мс задержки снижают выручку на 1%. Исследование Portent 2019 года показало: сайты, загружающиеся за 1 секунду, конвертируют в 3 раза лучше, чем те, что грузятся 5 секунд. На практике это означает, что работа с кэшем — не техническая задача исключительно для разработчиков, а прямой рычаг роста продаж, который маркетолог должен уметь ставить в приоритет.

Маркетолог регулярно сталкивается с последствиями кэширования, не всегда понимая их причину. Когда после внесения правок страница выглядит по-старому — виноват кэш, браузерный или серверный. Когда данные Яндекс.Метрики или Google Analytics показывают устаревший Title страницы в отчёте, это следствие кэширования на уровне поисковика. Знание принципов работы кэша позволяет диагностировать проблему за минуты, а не часами гадать, почему изменения не применились. Ещё один важный момент: A/B-тесты и персонализация требуют точной настройки заголовков кэширования — иначе разные пользователи видят одну и ту же закэшированную версию страницы, что убивает эксперимент и делает его результаты недостоверными. Понимание кэша делает маркетолога более автономным при работе с техническими командами и снижает время на согласование правок.

Как работает кэш

1. Запрос поступает в систему кэширования. Браузер или CDN-узел отправляет HTTP-запрос с указанием URL страницы. Прежде чем запрос попадёт к PHP-коду или базе данных, система кэширования проверяет, существует ли в хранилище актуальная запись для этого URL. Проверка занимает доли миллисекунды, потому что кэш хранит данные в оперативной памяти (Redis, Memcached) или на быстром SSD-диске (Varnish, Nginx). Именно скорость этой проверки определяет, насколько кэш эффективен — хороший кэш добавляет к обработке не более 1-2 мс.
2. Попадание в кэш (cache hit). Если запись найдена и её срок жизни (TTL — time to live) не истёк, сервер возвращает готовую копию без обращения к базе данных и без выполнения серверного кода. Пользователь получает ответ за 5-20 мс вместо 200-800 мс при обычной генерации страницы. Степень попадания в кэш называют hit rate — для хорошо настроенного сайта этот показатель составляет 80-95%. Если hit rate ниже 50%, это сигнал о неправильных настройках кэширования или слишком коротком TTL.
3. Промах кэша (cache miss). Если запись не найдена или TTL истёк, запрос уходит на «настоящий» сервер: выполняется код, делаются запросы к базе данных, формируется HTML-ответ. Сформированная страница одновременно отправляется пользователю и сохраняется в кэш для следующих запросов. Первый пользователь получает полное время ответа, все последующие — быстрый ответ из кэша. Этот первый запрос после обновления сайта называют «прогревом кэша» (cache warming) и его иногда выполняют специальными скриптами, чтобы пользователи не ощутили замедления.
4. Инвалидация кэша. Когда контент на сайте меняется — редактируется статья, обновляется цена товара — кэшированная копия устаревает. Система должна её удалить или пометить как невалидную, иначе пользователи продолжают видеть старые данные. Распространённые стратегии: удаление по TTL (кэш живёт N минут и обновляется автоматически), принудительный сброс через API (CMS сигнализирует кэшу об изменении конкретной страницы), тегированный кэш (Varnish поддерживает теги, позволяющие сбросить все страницы, связанные с конкретным продуктом или категорией). Неправильная инвалидация — главная причина, по которой пользователи видят устаревший контент.
5. Браузерное кэширование статических ресурсов. Браузер сохраняет CSS, JavaScript, изображения и шрифты в локальный кэш на устройстве пользователя. Заголовок Cache-Control: max-age=31536000 указывает браузеру хранить файл год без повторных запросов к серверу. При изменении файла URL меняют с помощью версионирования — добавляют хэш или номер версии в имя файла, что заставляет браузер скачать новую версию. Правильное браузерное кэширование сокращает количество HTTP-запросов при повторных визитах на 60-80% и напрямую влияет на показатель FID в Core Web Vitals.
6. CDN-кэширование. Сети доставки контента (Cloudflare, Akamai, Fastly) хранят кэш на серверах, физически близких к пользователю. Запрос из Новосибирска обрабатывается на ближайшем CDN-узле, а не на сервере в Москве, что сокращает задержку на 50-150 мс в зависимости от географии. CDN берут на себя значительную часть нагрузки, особенно по статическим ресурсам, и защищают сервер в период пиковых нагрузок. Cloudflare на бесплатном тарифе закрывает базовые потребности большинства малых и средних проектов.

Виды кэша

• Браузерный кэш. Хранится непосредственно на устройстве пользователя и управляется HTTP-заголовками: Cache-Control, Expires, ETag, Last-Modified. Браузер сохраняет статические ресурсы страницы и при повторном посещении загружает их с диска, а не из сети. Google PageSpeed Insights отдельно проверяет наличие правильных заголовков кэширования и снижает оценку за их отсутствие. Для маркетолога важно понимать: именно этот тип кэша чаще всего мешает увидеть свежие правки сайта после публикации — решение простое: открыть страницу в режиме инкогнито или сбросить кэш браузера через Ctrl+Shift+Delete.
• Серверный кэш страниц. Хранится на стороне сервера, обычно в оперативной памяти (Varnish, Nginx microcaching) или файловой системе. Готовый HTML сохраняется и отдаётся следующим пользователям без запуска PHP или Python и без обращения к базе данных. Этот вид кэша наиболее критичен для WordPress, где генерация страницы предполагает 20-80 запросов к базе данных. WP Rocket, W3 Total Cache и Nginx FastCGI Cache — типичные инструменты этого уровня. Серверный кэш снижает нагрузку на сервер в 10-50 раз и делает сайт устойчивым к пиковым нагрузкам.
• Кэш объектов (Object Cache). Кэширует результаты конкретных операций — например, результат SQL-запроса «получи 10 последних статей блога» или данные из внешнего API. Redis и Memcached — стандартные инструменты для этого уровня. В отличие от полностраничного кэша, объектный кэш позволяет кэшировать части данных и обновлять их независимо друг от друга. Для e-commerce с динамическими ценами это оптимальное решение: кэшируются все данные о товарах, кроме цен и остатков, которые тянутся напрямую из базы в реальном времени.
• CDN-кэш. Распределённая сеть серверов кэширует и доставляет контент из точки, ближайшей к пользователю. Cloudflare — самый распространённый вариант для российских проектов. CDN особенно эффективен для статических ресурсов — изображений, PDF-файлов, видео — и рекомендуется для сайтов с аудиторией в нескольких регионах. Помимо скорости, CDN защищает сервер от DDoS-атак, пропуская трафик через свою инфраструктуру, — это дополнительный аргумент в пользу подключения для коммерческих проектов любого масштаба.
• Кэш базы данных. MySQL и PostgreSQL имеют встроенные механизмы кэширования запросов в оперативной памяти. Для более гибкого управления используют ProxySQL перед MySQL или PgBouncer перед PostgreSQL. Этот вид кэша критичен для сайтов с активным чтением данных — новостных порталов, агрегаторов, сервисов сравнения цен. Правильная настройка кэша базы данных снижает количество реальных дисковых операций в 5-10 раз при том же числе запросов от пользователей.
• Кэш приложения (Application Cache). Реализуется на уровне кода приложения: фреймворки Django, Laravel, Symfony имеют встроенные механизмы кэширования произвольных данных с заданным TTL. Разработчик может закэшировать результат любой функции — от расчёта скидки до формирования блока рекомендаций. Этот подход требует планирования на этапе разработки, но даёт максимальный контроль: можно точно решить, какие данные должны всегда быть актуальными, а какие допустимо показывать с задержкой в несколько минут. Для сложных e-commerce проектов кэш приложения — самое гибкое и эффективное решение из всех перечисленных.

Сравнение браузерного и серверного кэша

Пример использования

Интернет-магазин бытовой техники в Екатеринбурге с трафиком 25 000 визитов в месяц работал на WordPress без кэширования. Средняя скорость загрузки страницы каталога составляла 4.1 секунды, показатель LCP — 5.8 секунды (значительно хуже порога Core Web Vitals). Во время акции «Черная пятница» при одновременном заходе 120 пользователей сервер падал с ошибкой 504 Gateway Timeout, сайт был недоступен 40 минут. Конверсия в заказ составляла 0.9%, показатель отказов на мобильных устройствах — 68%. Данные Яндекс.Метрики фиксировали, что 41% пользователей покидали сайт, не дождавшись полной загрузки первой страницы.

Разработчик установил WP Rocket для серверного кэша страниц и подключил Redis Object Cache для кэширования запросов к базе данных, затем добавил Cloudflare CDN. Настройка заняла один рабочий день. Через 2 недели после запуска средняя скорость загрузки снизилась до 1.2 секунды, LCP — до 1.9 секунды (ниже порога Core Web Vitals), hit rate кэша составил 89%. Следующая акция прошла без единого падения при пиковой нагрузке 380 одновременных пользователей. За 60 дней после внедрения кэша конверсия выросла с 0.9% до 1.8%, показатель отказов на мобильных снизился с 68% до 47%. При прежнем бюджете на рекламу выручка выросла на 100% — без изменения ассортимента, цен и содержания страниц.

Частые вопросы