CDN: что это и как ускоряет загрузку сайта

CDN — распределённая сеть серверов, которая отдаёт посетителю копии файлов и ответов сайта из подходящего узла. Полное название Content Delivery Network переводят как «сеть доставки контента». Она уменьшает расстояние до пользователя и снимает часть повторяющихся запросов с основного сервера.

CDN не ускоряет всё автоматически. Лучше всего кешируются одинаковые для многих посетителей файлы: изображения, стили, JavaScript, шрифты и загрузки. Страницы личного кабинета, корзина и ответы с персональными данными требуют отдельных правил или полного запрета общего кеширования.

Откуда CDN берёт файлы

Сервер, на котором находится исходная версия сайта, называют origin. У CDN есть пограничные узлы — серверы в разных точках сети. В документации также встречаются названия edge server и PoP, то есть точка присутствия.

Первый запрос к файлу обычно проходит так:

1. посетитель обращается к домену;
2. запрос приходит на пограничный узел CDN;
3. узел не находит подходящей свежей копии и запрашивает файл у origin;
4. origin возвращает файл и HTTP-заголовки;
5. CDN передаёт ответ посетителю и, если правила разрешают, сохраняет копию.

Отсутствие копии называют cache MISS. Следующий запрос может получить cache HIT: файл уже есть на узле и обращение к origin не требуется. Названия диагностических заголовков различаются у провайдеров, поэтому точный признак HIT нужно смотреть в документации выбранного CDN.

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

Как запрос попадает в CDN

Для подключения домена обычно меняют DNS-запись или включают proxy у DNS-провайдера. После этого публичный адрес ведёт в сеть CDN, а она уже знает адрес origin. Связь DNS и IP подробно разобрана в статье об A, AAAA и CNAME.

Есть две распространённые схемы:

• через CDN проходит весь веб-домен, а правила решают, что кешировать;
• для файлов создают отдельный домен, например static.example.com, и только он указывает на CDN.

Первая схема охватывает HTML и позволяет применять дополнительные сетевые функции. Вторая проще отделяет статику, но приложение должно формировать ссылки на отдельный домен. Выбор зависит от возможностей сервиса и структуры сайта.

При любом варианте HTTPS нужен и между посетителем и CDN, и между CDN и origin. Шифрование только первого участка оставляет внутреннее соединение без защиты и затрудняет проверку подлинности исходного сервера.

Что именно считается одной копией

Кешу нужен ключ — набор признаков, по которому один ответ отличают от другого. Базовый ключ учитывает метод и адрес. Провайдер может также включать параметры запроса, выбранные заголовки, язык или cookie.

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

Особенно осторожно обращаются с:

• страницами после входа;
• корзиной и оформлением заказа;
• API с авторизацией;
• результатами поиска;
• HTML, который меняется по языку или региону;
• ответами, устанавливающими пользовательские cookie.

CDN нельзя считать границей безопасности для приложения. Даже если origin закрыт от прямых посетителей, правила авторизации и разграничения данных остаются обязательными.

Как сайт сообщает срок хранения

HTTP-заголовок Cache-Control передаёт правила кеширования. Его добавляет приложение, веб-сервер или настройка CDN в ответ на запрос; сам следующий фрагмент не является командой для терминала. Такой набор директив подходит только публичному ответу, одинаковому для всех посетителей:

Cache-Control: public, max-age=300, s-maxage=3600

max-age=300 разрешает считать ответ свежим в течение 300 секунд. s-maxage=3600 задаёт отдельный срок для общих кешей, к которым относится CDN. public явно разрешает хранение в общем кеше даже в случаях, когда оно иначе было бы ограничено.

Для персонального ответа используют private: браузер пользователя может хранить его по остальным правилам, общий кеш — нет. Директива no-store просит вообще не сохранять ответ. Эти указания нужно формировать в приложении или на веб-сервере с учётом содержания, а не назначать одинаково всему домену.

Истечение срока не обязательно означает немедленное удаление файла. Копия становится устаревшей, после чего кеш может проверить её у origin с помощью условного запроса. Если содержимое не изменилось, сервер подтверждает это ответом 304 без повторной передачи всего тела.

Почему файлам полезны версии в имени

Для готовой статики удобно задавать долгий срок хранения и менять URL при изменении содержимого:

/assets/app.a84c12.js
/images/logo.2026-09.webp

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

Файл с версией нельзя менять на месте. Иначе один URL некоторое время будет означать разное содержимое. Для HTML обычно выбирают короткий срок или обязательную проверку свежести, поскольку именно HTML содержит ссылки на новые версии ресурсов.

Как проверить, что CDN работает

После подключения сначала откройте сайт обычным способом и убедитесь, что сертификат действителен, стили и изображения загружаются, вход и формы работают. Затем запросите заголовки публичного статического файла с локального компьютера:

curl --head https://example.com/assets/app.css

Замените домен и путь реальным публичным файлом. Команда ничего не меняет и показывает только заголовки. Проверьте код ответа, Cache-Control, Age и фирменный заголовок состояния кеша, если он описан провайдером. Age показывает, сколько секунд ответ находился в кеше, но его отсутствие само по себе не доказывает неисправность.

Повторите команду через несколько секунд. На первом запросе возможен MISS, на следующем — HIT. Если состояние не меняется, проверьте:

• допускает ли тип ответа кеширование по умолчанию;
• не отправляет ли origin private или no-store;
• не устанавливается ли cookie;
• входит ли расширение или код ответа в правила CDN;
• одинаков ли ключ у двух запросов.

Не проверяйте только главную страницу: HTML может намеренно не кешироваться, пока изображения и стили успешно обслуживаются с edge-узлов.

Очистка кеша и безопасный возврат

При срочной замене ошибочного файла очистите конкретный URL в панели или API CDN. Полная очистка заставит все узлы снова обратиться к origin и может создать резкий всплеск нагрузки. После очистки запросите файл и убедитесь, что его содержимое и заголовки обновились.

Если после включения CDN сломалась авторизация или посетители видят чужие данные, немедленно отключите кеширование затронутых путей и очистите их копии. Затем найдите правило, которое допустило общий кеш. Простого ожидания окончания срока недостаточно для чувствительных данных.

Для временного возврата обычно переводят DNS-запись в режим без proxy или возвращают прежнее значение. Учитывайте DNS-кеш и не удаляйте настройки origin до завершения проверки. Если используется Cloudflare, безопасный порядок переключения описан в статье о подключении Cloudflare DNS.

Что CDN не заменяет

CDN не является резервной копией: кеш неполон, автоматически меняется и может быть очищен. Он не исправляет медленную базу данных, тяжёлый JavaScript или неоптимизированные изображения. Сначала измерьте, какая часть загрузки занимает время.

Сжатие и корректные размеры файлов остаются полезны независимо от географии. Практические настройки собраны в руководствах о gzip в Nginx и об оптимизации изображений.

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

Источники

• RFC 9111: кеширование HTTP
• MDN: заголовок Cache-Control
• Cloudflare: поведение кеша по умолчанию
• Cloudflare: обзор cache keys