Что такое CDN и когда она нужна сайту: кеш, скорость и расходы

CDN — сеть узлов доставки содержимого. Вместо получения каждой картинки или CSS-файла непосредственно с основного сервера посетитель может получить копию с ближайшего доступного узла. Это помогает при подходящей географии аудитории, больших объёмах повторно запрашиваемой статики и заметной сетевой задержке.

Но CDN не исправляет медленный SQL-запрос сама по себе и не отменяет настройку основного сайта. Полезный вопрос звучит так: какой конкретно ресурс мы хотим ускорить, кто его получает и как будем обновлять копии? Разберём это на примерах блога, приложения и интернет-магазина.

CDN, хостинг и S3 выполняют разные задачи

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

Компонент	Что делает	Чего сам по себе не гарантирует
VPS или веб-хостинг	Выполняет приложение, хранит сайт	Близость ко всем посетителям мира
S3-хранилище	Хранит объекты: изображения, архивы, копии	Быструю доставку через распределённую сеть
CDN	Доставляет и кеширует подходящее содержимое	Быструю генерацию некешируемого ответа приложения
Кеш браузера	Повторно использует ресурс на устройстве	Копию для другого посетителя или нового устройства

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

Когда подключение оправдано

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

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

Для диагностики разделите время ожидания HTML и загрузку ресурсов страницы. Инструкция по поиску причин медленной загрузки помогает не спутать тяжёлый frontend с медленной базой. Если bottleneck находится в коде приложения, одна смена DNS на CDN проблему не решит.

Начать со статики

Удобная первая область — публичные изображения, стили и JavaScript с версионированными именами: например, app.a91f2.css. После изменения создаётся новый URL, поэтому старую копию не нужно экстренно вытеснять из всех промежуточных кешей.

Для обновляемого файла с постоянным именем, такого как /logo.webp, понадобится осмысленный TTL и способ очистки кеша. Иначе редактор заменит файл на сервере, а часть посетителей продолжит видеть прежний.

На первом этапе исключите личный кабинет, корзину, оплату, административные страницы и API с персональными ответами. HTML тоже может кешироваться, но это отдельная задача с правилами для cookies, авторизации, вариантов языка и состояния пользователя. Правило «кешировать всё» опасно применять без разбора.

Настроить Cache-Control

Заголовок ответа помогает понять, как долго содержимое можно хранить и кому его можно повторно использовать:

Cache-Control: public, max-age=3600

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

Не выставляйте большой публичный TTL для одной и той же страницы, которая в зависимости от cookie возвращает данные разных пользователей. Наличие Set-Cookie и Authorization требует отдельной проверки поведения конкретной CDN. Настройки провайдера могут переопределять заголовки origin, поэтому изучать нужно и ответ сервера, и действующие правила доставки.

Проверить заголовки можно через инструмент HTTP-заголовков или командой:

curl -sSI --max-time 15 https://example.org/assets/app.a91f2.css

В Windows используйте curl.exe. Команда читает заголовки одного ресурса и не измеряет целиком загрузку страницы в браузере.

Проверить попадание в кеш

У разных CDN разные диагностические заголовки: встречаются Age, Via, X-Cache и собственные статусы провайдера. Их отсутствие не доказывает, что кеширования нет. Смотрите документацию и, при доступе, статистику выдачи.

Для учебного опыта мы использовали два локальных Nginx-хоста: источник и кеширующий прокси. Повторный запрос одного CSS-файла изменил статус с MISS на HIT. Это демонстрирует механизм HTTP-кеша, а не скорость распределённой коммерческой сети.

В том же опыте ответы private, no-store и ответы с Set-Cookie не становились HIT. Запрос с заголовком авторизации обходил кеш. Это полезнее одной демонстрации быстрой картинки: ошибочно закешированный личный ответ может быть существенно опаснее медленной статики.

Разобраться с параметрами URL

Адреса photo.webp?width=400 и photo.webp?width=1200 могут возвращать разные изображения. Если CDN игнорирует параметр width, посетителю может достаться неправильный вариант. Если же учитывать все рекламные параметры без разбора, появятся лишние копии одинакового содержимого и доля попаданий уменьшится.

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

На локальном стенде новый query string давал отдельный MISS; повтор того же полного URL — HIT. У коммерческой CDN это поведение зависит от правил, поэтому результат локального примера нельзя автоматически переносить на любую панель.

Посчитать трафик и расходы

Разделяйте трафик origin → CDN и CDN → посетитель. Кроме объёма могут оплачиваться запросы, очистка кеша, журналы, отдельные регионы и дополнительные функции. Условия S3 и условия доставки также могут быть разными.

Учебный расчёт: 2 000 посещений в день, в среднем 2 МБ кешируемых ресурсов на посещение, 30 дней. Получается около 120 ГБ доставленного содержимого в десятичном расчёте. Если 80% байтов выдаются из кеша, на origin приходится примерно 24 ГБ такого содержимого, без учёта служебных запросов и обновлений.

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

Сведите расходы в калькуляторе стоимости инфраструктуры и сопоставьте с бюджетом самого VPS. Дешёвая выдача статики не компенсирует случайно включённые платные опции или отсутствие лимита расходов.

Подключать постепенно и проверить возврат

Начните с одного класса публичных ресурсов или отдельного домена статики. До изменения DNS сохраните прежние записи и проверьте поддержку HTTPS на новом имени. Сертификат origin и сертификат на стороне CDN — отдельные участки цепочки, оба должны соответствовать своей задаче.

Проверьте CSS, шрифты, изображения, скачивание файлов и разные устройства. Для ресурсов с другого домена могут потребоваться корректные CORS-правила и обновление CSP. Не открывайте все источники через *, если приложению нужны лишь конкретные домены.

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

После подключения повторите те же сценарии и замеры, что до него. Контролируйте ошибки, время загрузки, счёт провайдера и нагрузку origin. Финальный чек-лист проверки сайта поможет убедиться, что вместе со статикой продолжают работать формы и навигация.