Настройка CDN для сайта: реальное ускорение и защита без поломки логина и корзины

CDN — это не “галочка для скорости”, а управляемая инфраструктура доставки контента: статические файлы и медиа отдаются с ближайших узлов, снижается нагрузка на origin-сервер, ускоряется первый экран и повышается устойчивость при пиковом трафике. Но при неправильной настройке CDN ломает обновления, кеширует личные данные и “убивает” формы. Мы настраиваем CDN так, чтобы ускорение было реальным и безопасным.

Когда CDN действительно нужен

• аудитория распределена по регионам, а latency заметно влияет на UX;
• много медиа (каталоги, галереи, портфолио), высокая стоимость трафика/канала;
• на пиках нагрузка “кладёт” сервер или растёт число 5xx/таймаутов;
• нужно ускорить LCP и разгрузить origin без пересборки сайта;
• нужна базовая защита: DDoS, WAF, rate limiting, боты.

Почему CDN “подключили”, а стало хуже (типовые провалы)

• Кешируют динамику — личный кабинет, корзину, API, формы. Итог: ошибки и утечки.
• Нет purge/инвалидации — “обновления не видны”, пользователи получают старые файлы.
• Неправильные TTL и заголовки — либо не кешируется ничего, либо кешируется всё подряд.
• HTTPS/TLS настроен формально — появляются циклы редиректов, mixed content, проблемы с cookies.
• Не учитывают устройство сайта — одинаковые правила для статики, HTML и API.

Что мы настраиваем (по слоям)

1) Архитектура: что через CDN, а что напрямую

• сегментация трафика: статические ресурсы / медиа / HTML / API;
• исключения из кэша: личные страницы, корзина, авторизация, динамика, вебхуки;
• выбор режима: проксирование DNS/HTTP, “full” или “static-only” сценарий.

2) Кэширование: правила, TTL, purge

• Cache-Control/ETag/Last-Modified: где можно immutable, где нельзя;
• TTL на уровне путей/типов контента, bypass по cookies/headers;
• инвалидация (purge): ручная и/или автоматическая по релизам;
• защита от “кэш-помоек”: vary, query string rules, нормализация.

3) Скорость: реальное ускорение, а не “косметика”

• снижение latency за счёт edge-узлов;
• сжатие и оптимальная отдача статики (Brotli/Gzip — по стеку);
• опционально: оптимизация изображений на лету (если провайдер поддерживает);
• контроль влияния на TTFB и LCP (до/после).

4) HTTPS/TLS и доменная часть

• корректный режим SSL (без редирект-петель), HSTS при готовности;
• настройка сертификатов и цепочек, проверка SNI;
• правильная работа cookies/SameSite/Secure при проксировании.

5) Безопасность: WAF, DDoS, боты

• WAF-профили под тип сайта: формы, админки, API;
• rate limiting для чувствительных endpoints (логин, восстановление, поиск);
• блоки ботов/сканеров, базовая защита от DDoS на edge.

KPI и измеримость

• Cache HIT ratio по статике и медиа (рост доли отдачи с edge);
• TTFB (особенно на географии) — снижение задержки ответа;
• LCP (для страниц с “тяжёлым” первым экраном);
• снижение нагрузки на origin: запросы/сек, исходящий трафик, CPU;
• устойчивость: меньше 5xx/таймаутов на пиковых нагрузках.

Критерии “готово”

• определено, что кешируем, а что исключаем (HTML/динамика/API);
• правила TTL и purge работают: обновления применяются предсказуемо;
• формы, авторизация, личный кабинет и корзина работают стабильно;
• метрики до/после зафиксированы, улучшения подтверждены замерами;
• есть регламент: как выпускать релизы, не ломая кэш и скорость.

Что мы не делаем

• не кешируем “всё подряд”, чтобы получить красивую цифру в тесте;
• не включаем агрессивные правила без проверки критических сценариев;
• не оставляем CDN “самотёком” без purge-стратегии и мониторинга.

Сроки и стоимость

Обычно: 1–2 дня и от 10 000 ₽.
Зависит от провайдера, схемы доменов/DNS и наличия личного кабинета/API, где важны исключения из кэша.