Сжатые картинки и аккуратный фронтенд — только половина скорости. Вторая половина живёт на сервере: сколько миллисекунд проходит от запроса до первого байта ответа, сколько раз движок заново собирает одну и ту же страницу и как далеко физически находится посетитель от железа. Кеширование и CDN решают именно эти задачи. Ниже — как мы раскладываем кеш по слоям, какие цифры получаем на проектах и где кеш способен навредить сильнее, чем помочь.
Почему сервер тормозит, даже если страница «лёгкая»
Возьмём типичную страницу каталога на 1С-Битрикс или WooCommerce. Чтобы её отдать, движок подключает ядро, читает настройки, делает от 40 до 300 запросов к базе данных, проверяет права пользователя, собирает меню, фильтры, блоки «С этим товаром покупают» и только потом генерирует HTML. Даже на хорошем сервере это 400–1500 мс, а при наплыве посетителей — несколько секунд. При этом страница может весить всего 60 КБ, и её «лёгкость» никак не помогает: время уходит не на передачу, а на вычисления.
Показатель, который это отражает, называется TTFB — время до первого байта. Браузер ничего не может нарисовать, пока не получит начало HTML, поэтому медленный TTFB тянет за собой все остальные метрики: отрисовку первого контента, LCP, ощущение «сайт подвисает». Для коммерческого сайта мы считаем нормой TTFB до 200 мс для закешированных страниц и до 600 мс для динамических.
Кеширование по сути означает одну простую идею: если результат дорогой операции уже был получен и не изменился, его не нужно вычислять заново. Вопрос лишь в том, на каком уровне хранить готовый результат и как понять, что он устарел. Именно второе — инвалидация — и есть главная сложность всей темы.
Слои кеширования: от браузера до базы данных
Кеш — это не одна галочка в админке, а несколько независимых уровней. Каждый экономит свою часть работы, и у каждого свои риски. Удобно представлять их как цепочку: запрос посетителя идёт от браузера к серверу, и на любом звене может быть перехвачен готовым ответом.
Браузерный кеш
Браузер хранит у себя стили, скрипты, шрифты и картинки по заголовкам Cache-Control. При повторном визите они не скачиваются вовсе. Бесплатно и очень эффективно для постоянной аудитории.
CDN и прокси
Сеть серверов, расположенных ближе к посетителю, отдаёт статику, а иногда и целые HTML-страницы. Снимает нагрузку с основного сервера и сокращает сетевую задержку.
Страничный кеш
Nginx, Varnish или модуль CMS сохраняют готовый HTML страницы. Повторный запрос обслуживается за 5–30 мс без запуска PHP и обращений к базе.
Объектный кеш и OPcache
Redis или Memcached хранят результаты тяжёлых запросов и вычислений, OPcache — скомпилированный PHP-код. Ускоряют даже те страницы, которые целиком кешировать нельзя.
Браузерный кеш и версионирование файлов
Самый дешёвый выигрыш — правильные заголовки для статики. Файлы CSS, JS и шрифты можно кешировать на год, если в их имени есть хеш версии вида app.3f9a1c.css: при изменении стилей меняется имя, и браузер скачивает новый файл, а старый просто перестаёт использоваться. Ошибка, которую мы часто видим при аудитах, — кеш на 7 дней для файлов без версии. В итоге после правки дизайна часть посетителей неделю видит «сломанную» вёрстку: новый HTML со старыми стилями.
Страничный кеш
Здесь кроется основной прирост. Страница статьи, услуги или карточки товара для анонимного посетителя одинакова для всех, значит, её можно один раз сгенерировать и затем отдавать из памяти. На проекте «магазин сантехники» с каталогом около 18 000 позиций включение страничного кеша на уровне Nginx снизило средний TTFB карточек с 1,1 секунды до 90 мс, а нагрузку на процессор — примерно в шесть раз. Сервер, который раньше «задыхался» при рекламной рассылке, стал держать пиковый трафик без апгрейда тарифа.
Объектный кеш
Не всё можно закешировать целиком: корзина, личный кабинет, страница поиска с параметрами. Но даже внутри них много повторяющихся вычислений — дерево разделов, список брендов, настройки доставки. Redis хранит эти куски в оперативной памяти, и PHP получает их за доли миллисекунды вместо похода в базу. Для WordPress это отдельный плагин и пара строк конфигурации, в Битриксе — штатный механизм управляемого кеша, который достаточно переключить на Redis или Memcached.
Что такое CDN и кому он действительно нужен
CDN — сеть распределённых серверов, которые хранят копии ваших файлов и отдают их с ближайшей к посетителю точки. Посетитель из Новосибирска получает картинки не из московского дата-центра за 50–60 мс сетевой задержки на каждый запрос, а с узла в своём регионе за 5–10 мс. На странице с сотней ресурсов эта разница складывается в ощутимые секунды, особенно на мобильном интернете.
Вторая функция CDN — разгрузка. Основной сервер перестаёт отдавать гигабайты картинок и видео и занимается только тем, что действительно требует вычислений. Плюс многие CDN умеют на лету конвертировать изображения в WebP и AVIF, сжимать текстовые файлы по Brotli и фильтровать мусорный трафик от ботов.
Но CDN не волшебная кнопка. Если аудитория сайта — Москва и область, а сервер стоит в Москве, выигрыш в задержке будет минимальным: посетитель и так рядом. Если медленный именно HTML из-за тяжёлого бэкенда, CDN для статики ничего не исправит — нужно разбираться с серверной частью. Мы рекомендуем CDN в трёх случаях: аудитория по всей стране или за рубежом, много тяжёлого медиаконтента, регулярные пики трафика от рассылок, акций или телевизионной рекламы.
Подключая CDN, проверьте, что он не кеширует ответы с cookie сессии и не отдаёт закешированную страницу авторизованному пользователю. Однажды мы разбирали инцидент, когда после «быстрого подключения» CDN посетители видели в шапке имя случайного покупателя, который первым открыл страницу. Данные не утекли, но репутационный урон был бы серьёзным.
Что можно кешировать, а что нельзя
Главный принцип: кешируется то, что одинаково для всех посетителей и меняется редко. Всё персональное и всё, что меняется в реальном времени, либо не кешируется, либо подгружается отдельным запросом поверх закешированной страницы. Для удобства мы составляем такую таблицу на каждом проекте ещё на этапе архитектуры.
| Тип контента | Где кешировать | Срок жизни | Как сбрасывать |
|---|---|---|---|
| CSS, JS, шрифты с хешем в имени | Браузер, CDN | Год | Новое имя файла при сборке |
| Изображения товаров | Браузер, CDN | 30 дней и больше | Новый адрес при замене фото |
| Статьи, страницы услуг | Страничный кеш, CDN | Часы или сутки | Автоматически при сохранении в админке |
| Карточки и списки товаров | Страничный кеш | 15–60 минут | При обмене с 1С по затронутым товарам |
| Цены и остатки | Объектный кеш или без кеша | 1–5 минут | По событию изменения |
| Корзина, кабинет, оформление заказа | Не кешируются | — | — |
Отдельно стоит сказать о ценах и остатках. Если магазин обновляет их из учётной системы раз в 15 минут, а кеш карточки живёт сутки, покупатель увидит старую цену, положит товар в корзину и получит другую сумму при оформлении. Это прямой путь к жалобам и отказам. Решение — либо сбрасывать кеш конкретных товаров при каждом обмене, либо выводить цену и наличие отдельным лёгким запросом, а остальную карточку держать в кеше. Подробнее о связке с учётной системой мы писали в статье об интеграции интернет-магазина с 1С.
Инвалидация: самая сложная часть
В программировании есть известная шутка о том, что трудных задач всего две, и одна из них — инвалидация кеша. Включить кеш легко. Сделать так, чтобы он сбрасывался ровно тогда, когда нужно, и только для тех страниц, которые изменились, — уже инженерная работа.
Простейший подход — сброс по времени: страница живёт 30 минут, потом генерируется заново. Он надёжен, но неточен: изменения появляются с задержкой, а популярные страницы всё равно пересчитываются, даже если ничего не менялось. Более зрелый подход — сброс по событию, или тегированный кеш. Каждая закешированная страница помечается тегами: «товар 1523», «раздел смесители», «бренд такой-то». Когда в админке меняется товар, система сбрасывает только страницы с его тегом. В Битриксе это встроено в ядро, для Laravel и других фреймворков реализуется через теги Redis.
Третья частая проблема — «лавина» при сбросе. Если разом очистить весь кеш крупного магазина в час пик, сотни запросов одновременно пойдут в базу, и сервер может лечь. Поэтому полную очистку мы делаем ночью или прогреваем кеш скриптом: робот проходит по карте сайта и заранее генерирует самые посещаемые страницы. Ещё один приём — отдавать устаревшую копию, пока в фоне готовится новая. Посетитель получает быстрый ответ, а данные обновляются через несколько секунд.
Составить карту страниц
Разделить все типы страниц на статичные, полудинамичные и персональные, определить источник изменений для каждого типа.
Выбрать стратегию сброса
Для контентных страниц — сброс при сохранении, для каталога — по тегам при обмене, для статики — версионирование имён файлов.
Вынести персональное
Счётчик корзины, имя пользователя, избранное подгружаются отдельным запросом, чтобы основная страница оставалась общей для всех.
Настроить прогрев
После деплоя и ночной очистки скрипт проходит по нескольким сотням самых посещаемых адресов.
Проверить под нагрузкой
Нагрузочный тест показывает, как сайт ведёт себя при пустом и при заполненном кеше, и где узкие места остаются.
Серверные настройки, которые дают прирост без кеша
Прежде чем строить сложную схему кеширования, стоит убедиться, что базовые вещи на сервере в порядке. Нередко именно они дают половину эффекта. Мы начинаем любой аудит скорости с этого списка, и на старых проектах почти всегда что-то находится.
- Актуальная версия PHP: переход со старой ветки на свежую даёт 20–40% прироста производительности без изменения кода.
- Включён OPcache с достаточным объёмом памяти, чтобы весь код проекта помещался целиком.
- Сжатие Brotli или gzip для HTML, CSS, JS и SVG — экономит до 70–80% трафика текстовых файлов.
- Протокол HTTP/2 или HTTP/3: параллельная загрузка ресурсов по одному соединению.
- Индексы в базе данных на поля, по которым идёт фильтрация и сортировка каталога.
- Сессии и кеш хранятся в Redis, а не в файлах на диске.
- Сервер с SSD или NVMe-дисками и достаточным объёмом оперативной памяти для базы.
- Отключены неиспользуемые модули и плагины, которые подключаются на каждой странице.
Хостинг тоже имеет значение: на дешёвом виртуальном тарифе с соседями, которые делят процессор, никакой кеш не спасёт от периодических провалов. Об этом подробно — в материале о том, как выбрать хостинг для сайта компании.
Как измерить результат и не обмануть себя
Самая частая ошибка при оценке кеша — измерять скорость со своего компьютера, сразу после того как открыл страницу. Она уже закеширована и в браузере, и на сервере, поэтому всё летает. Реальный посетитель может попасть на холодный кеш, прийти с мобильного интернета и из другого города. Поэтому мы измеряем несколько вещей отдельно.
Во-первых, TTFB при холодном и горячем кеше: первый показывает, насколько тяжёл сам бэкенд, второй — эффективность кеширования. Во-вторых, процент попаданий в кеш (hit ratio): для контентного сайта нормально 90% и выше, для магазина — 70–85%. Если показатель ниже 50%, кеш почти не работает, скорее всего, его «пробивают» лишние параметры в адресах вроде меток рекламных кампаний. Их стоит исключить из ключа кеша. В-третьих, полевые данные реальных пользователей — отчёты о Core Web Vitals в панелях вебмастеров и в системе аналитики.
И наконец, нагрузочное тестирование. Оно показывает, сколько одновременных посетителей выдерживает сайт до деградации. Для одного из клиентов — интернет-магазина товаров для дома — после настройки кеша и CDN этот предел вырос со 120 до 1 500 одновременных сессий на том же сервере. Это позволило спокойно пережить сезонную распродажу, на которой в прошлый раз сайт падал дважды.
Типичные ошибки при настройке кеша
За годы аудитов мы собрали набор повторяющихся проблем. Почти все они не про сложные технологии, а про невнимательность к деталям.
Почему после включения кеша перестали работать формы?
Скорее всего, в закешированную страницу попал одноразовый токен защиты от подделки запросов. Все посетители получают один и тот же устаревший токен, и сервер отклоняет отправку. Токен нужно подгружать отдельным запросом или исключать страницы с формами из полного кеширования.
Почему мобильные пользователи видят десктопную версию?
Если сайт отдаёт разную вёрстку для разных устройств, а ключ кеша этого не учитывает, первая сгенерированная версия достаётся всем. Решение — адаптивная вёрстка с единым HTML или разделение кеша по типу устройства.
Почему изменения в админке не появляются на сайте?
Не настроен сброс кеша при сохранении, либо кеш остался в CDN. Нужно связать события CMS с очисткой нужных страниц и на CDN тоже — через API провайдера.
Нужно ли кешировать результаты поиска по сайту?
Популярные запросы — да, на короткое время, это заметно снижает нагрузку. Но ключ кеша должен учитывать все параметры запроса, иначе пользователь увидит чужую выдачу.
Отдельно упомянем ситуацию, когда кеш маскирует проблему. Сайт работает быстро, пока кеш тёплый, но после очистки или деплоя несколько минут «лежит». Это сигнал, что бэкенд неоптимален и кеш стал костылём. Такие проблемы мы разбираем при технической поддержке: профилируем медленные запросы, добавляем индексы, переписываем тяжёлые компоненты.
Главное о кешировании и CDN
Серверная скорость складывается из нескольких слоёв, и каждый решает свою задачу. Браузерный кеш с версионированием файлов почти бесплатен и должен быть на любом сайте. Страничный кеш даёт наибольший прирост для анонимных посетителей и снижает нагрузку в разы. Объектный кеш ускоряет то, что нельзя закешировать целиком. CDN оправдан при географически распределённой аудитории, тяжёлом медиаконтенте и пиковых нагрузках.
Ключевая сложность — не включить кеш, а правильно его сбрасывать: цены, остатки и персональные данные требуют отдельной логики. Начинайте с базовых настроек сервера, затем стройте схему кеширования по типам страниц, измеряйте результат на холодном кеше и под нагрузкой. Тогда скорость станет стабильным свойством сайта, а не результатом удачного замера с рабочего компьютера разработчика.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
