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

«Ваш сайт теперь глобально оптимизирован!» — обещают продавцы CDN, показывая красочные карты с серверами по всему миру. Шреко-зеленые точки от Балашихи до Сингапура, обещающие молниеносную доставку контента пользователям повсюду. Ваш ежемесячный счет отражает это глобальное покрытие премиальными ценами.

Но вот неудобная правда: для многих сайтов CDN не ускоряют их. Они делают медленнее. Инфраструктура, разработанная для ускорения доставки контента, становится узким местом (шутка про бывшую не подходит, говорим про узкие места) , добавляя задержку вместо ее уменьшения.

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

Индустрия обещаний против реальности

Глобальная индустрия CDN генерирует свыше $20 миллиардов ежегодно, продавая обещание скорости. Однако данные мониторинга производительности от Catchpoint показывают, что многие развертывания CDN фактически увеличивают общее время загрузки страниц из-за накладных расходов, о которых никто не говорит.

Исследования Real User Monitoring демонстрируют, что частота промахов кэша часто превышает 30% для типичных веб-сайтов, сводя на нет преимущества скорости, которые CDN должны обеспечивать.

Добро пожаловать к самой дорогой деградации производительности, которую можно купить.

Скрытые накладные расходы: DNS-штраф

Каждый CDN добавляет фундаментальный штраф производительности, о котором поставщики удобно забывают упомянуть. Накладные, бл, расходы DNS-запросов. Когда вы направляете трафик через CDN, вы добавляете дополнительный слой разрешения DNS, который может добавить 20-120 миллисекунд к каждому запросу.

Вот что вообще происходит, когда кто-то посещает ваш сайт с поддержкой CDN:

  1. DNS-запрос к CDN (20-50мс)

  2. Разрешение до ближайшего edge-сервера (10-30мс)

  3. Установление соединения с edge (50-150мс)

  4. Edge запрашивает origin (при промахе кэша: +100-500мс)

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

Комплексное исследование, опубликованное в arXiv, анализирующее публичные DNS-резолверы и CDN, обнаружило, что «медианные задержки Cloudflare-R по всем CDN и IP-версиям находятся в диапазоне 10.98 – 12.22 мс, в то время как диапазон Google составляет 15.94 – 21.88 мс».

Миф о попаданиях в кэш

Маркетинг CDN фокусируется на попаданиях в кэш, тех магических моментах, когда контент мгновенно доставляется с edge-сервера. Но они странно молчат о промахах кэша, которые происходят чаще, чем вы ожидаете.

Реальность соотношения попаданий в кэш индустрии:

  • Статический контент: 70-85% попаданий

  • Динамический контент: 40-60% попаданий

  • Персонализированный контент: 20-40% попаданий

  • API-запросы: 10-30% попаданий

Анализ производительности от CacheFly подтверждает, что промахи кэша могут сделать запросы через CDN в 2-3 раза медленнее прямого доступа к origin.

Расчет штрафа за промах кэша:

Прямой запрос к origin: 100-200мс.

CDN при промахе кэша:

DNS + routing overhead: 50-100мс

Edge → Origin: 100-200мс

Общий штраф: 150-300мс (на 50-150% медленнее)

HTTPS через CDN: двойная безопасность, двойные задержки

HTTPS добавляет еще один слой сложности, который CDN редко оптимизируют правильно. Анализ производительности SSL/TLS от Cloudflare показывает, что установление безопасных соединений через CDN часто требует "множественных рукопожатий":

Прямое HTTPS-соединение:

  • Клиент → Origin SSL handshake: ~200-300мс

CDN HTTPS-соединение:

  • Клиент → Edge SSL handshake: ~150мс

  • Edge → Origin SSL handshake: ~200мс

  • Общее время: ~350мс (+75% накладных расходов)

Исследование от Imperva о CDN и SSL/TLS объясняет, что этот штраф возникает потому, что «после установления первого этапа SSL/TLS-соединения, CDN все еще нужно инициировать второй процесс переговоров» с origin-сервером.

Географический парадокс: близость не гарантирует скорость

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

Штраф Азиатско-Тихоокеанского региона

Академическое исследование из arXiv обнаружило, что «большинство сценариев в Азии демонстрируют штраф IPv6 в задержке маппинга» и «Edgecast... штраф варьируется от 2.8мс (или 37%) для OpenDNS до 7.7мс (свыше 50%) для Quad9».

Вызов африканской связности

То же исследование показало, что «в Африке Fastly страдает от существенного штрафа задержки маппинга IPv6 по всем резолверам, с медианными задержками IPv6, которые в 2-3 раза выше, чем в IPv4».

Проблемы маршрутизации в Южной Америке

Региональный анализ показал, что «Quad9 значительно отстает в задержке маппинга в Южной Америке, причем каждый CDN, кроме Cloudflare-CDN».

Мониторинг производительности от CDN Planet демонстрирует, что CDN часто направляют трафик через неоптимальные пути.

Эффект умножения: накладные расходы на каждый ресурс

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

Типичная разбивка ресурсов веб-сайта:

  • HTML-документы: 1-5

  • CSS-файлы: 3-10

  • JavaScript-файлы: 5-20

  • Изображения: 20-100+

  • Шрифты: 2-10

  • API-вызовы: 10-50+

Анализ производительности от Kinsta показывает, что «время DNS-запросов может варьироваться от 20-120 миллисекунд».

Умножение накладных расходов соединения:

50 ресурсов × 50мс DNS overhead = 2.5 секунды дополнительной задержки.

При кэшировании DNS: 50 ресурсов × 10мс = 500мс накладных расходов.

Когда CDN помогает и когда вредит

CDN РЕАЛЬНО помогает, когда:

  • Глобальная аудитория с высокими задержками к origin

  • Преимущественно статический контент (изображения, видео)

  • Высокие коэффициенты попаданий в кэш (>80%)

  • Большие файлы (>1MB), где накладные расходы незначительны

  • DDoS-защита важнее чистой производительности

CDN руинит производительность, когда:

  • Региональная аудитория рядом с вашим origin-сервером

  • Динамический или персонализированный контент

  • Частые обновления контента

  • Небольшие файлы, где накладные расходы доминируют

  • Плохо настроенные правила кэширования

Синтетический мониторинг и реальный user experience

Поставщики CDN часто представляют данные производительности из синтетического мониторинга, которые не отражают реальный пользовательский опыт. Анализ синтетического мониторинга от AWS выявляет критические ограничения:

Разрывы между синтетическим и Real User Monitoring:

  • Синтетические тесты используют предварительно прогретый кэш

  • Тестирование из дата-центров не отражает реальные сетевые условия

  • Отсутствует вариативность сетевой задержки конечных пользователей

  • Игнорируются паттерны реального трафика

Стоимость CDN-накладных расходов

CDN-сервисы обычно стоят $50-500+ ежемесячно, потенциально ухудшая производительность. Проанализируем истинную стоимость CDN-накладных расходов:

Прямые расходы:

  • Плата за CDN: $50-500+/месяц

  • Овerage-расходы: $0.05-0.20/ГБ

  • SSL-сертификаты: $10-100/месяц

Скрытые расходы производительности:

  • DNS-задержка: +20-120мс на запрос

  • SSL-накладные расходы: +50-200мс на соединение

  • Штрафы промахов кэша: +100-500мс на промах

Тот же бюджет, вложенный в оптимизацию origin-сервера, часто дает превосходные результаты:

  • Апгрейд сервера: $100-300/месяц → постоянное улучшение

  • HTTP/2 оптимизация: разовая настройка → снижение на 200-500мс

  • База данных/кэш оптимизация: $50-200/месяц → снижение на 500-2000мс

Как измерить реальное влияние CDN

Если вы подозреваете, что ваш CDN скорее вредит, чем помогает производительности, вот как измерить реальное влияние:

Шаг 1: Базовые измерения

  • Используйте WebPageTest.org с реальными местоположениями пользователей

  • Мониторьте TTFB, LCP, CLS для ключевых страниц

  • Записывайте показатели в течение недели для установления базовой линии

Шаг 2: Тестирование обхода CDN

  • Настройте поддомен, указывающий прямо на origin

  • A/B тестируйте CDN vs. прямой origin

  • Измерьте разницу в реальных пользовательских показателях

Шаг 3: Анализ географической производительности

  • Тестируйте из различных глобальных местоположений

  • Идентифицируйте регионы, где CDN помогает vs. вредит

  • Фокусируйтесь на ваших основных рынках

Практические рекомендации

Оставьте ваш CDN, если:

  • Cache hit ratio >80% для критического контента

  • Глобальная аудитория с доказанными улучшениями

  • Большие медиа-файлы составляют >60% трафика

  • DDoS-защита критична для бизнеса

Оптимизируйте ваш CDN, если:

  • Cache hit ratio 60-80%

  • Смешанная производительность по регионам

  • Высокие накладные расходы DNS/SSL

Удалите ваш CDN, если:

  • Cache hit ratio <60%

  • Региональная аудитория показывает деградацию

  • Origin-сервер может обслуживать всю аудиторию эффективно

  • Стоимость превышает измеренные преимущества

Альтернативный путь к лучшей производительности

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

Вместо CDN инвестируйте в:

  • HTTP/2/HTTP/3 оптимизацию: уменьшает необходимость в множественных соединениях

  • Агрессивное кэширование браузера: уменьшает повторные запросы

  • Оптимизацию базы данных: устраняет медленные запросы в источнике

  • Сжатие и минификацию: уменьшает размеры передачи

  • CDN-качество инфраструктуры: премиум-хостинг часто превосходит CDN

Заключение: перестаньте платить за эффект плацебо

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

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

Суровая правда о производительности CDN:

  • 30-50% развертываний CDN ухудшают производительность

  • DNS-накладные расходы часто превышают географические преимущества

  • Промахи кэша делают «глобально оптимизированный» контент медленнее локального

  • Большинство конфигураций CDN неоптимальны из коробки

Перестаньте платить за эффект плацебо. Начните измерять реальную производительность.

Комментарии (6)


  1. CloudlyNosound
    12.09.2025 06:56

    Географический парадокс: близость не гарантирует скорость

    То же самое имеет место и в случае полного отказа от CDN.


  1. urvanov
    12.09.2025 06:56

    • HTML-документы: 1-5

    • CSS-файлы: 3-10

    • JavaScript-файлы: 5-20

    • Изображения: 20-100+

    • Шрифты: 2-10

    • API-вызовы: 10-50+

    Вот это нужно в первую очередь оптимизировать. А всякие CDN и прочее — это уже потом. В идеале должен быть один небольшой CSS файл, один небольшой JavaScript (или вообще без него), никаких подгружаемых шрифтов. И поменьше всяких вызовов API, а лучше без них. Картинки да, сейчас без них никуда. Но не пару десятков на одну страницу уж точно. В идеале должно получиться что-нибудь вроде такого, и никакой CDN не будет нужен.


    1. Sau
      12.09.2025 06:56

      Что-то вроде такого у автора, конечно, есть, только вот свой основной блог он ведёт почему-то в обычном формате: WordPress 6.8.2.


      1. urvanov
        12.09.2025 06:56

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


        1. Sau
          12.09.2025 06:56

          Было бы интересно посмотреть. Можно пользоваться и попадать в клуб сайтов до 10 кб: https://10kb.club/


  1. akakoychenko
    12.09.2025 06:56

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

    Без этой киллер фичи, даже, имея много ориджинов, все решения сомнительны. К примеру, попытки заставить dns отдавать разные ориджины сомнительны из-за того, что какой именно днс сервер будет спрашивать посетитель, и как тот сервер ответит - вещи неподконтрольные. Редиректы типа eu.mysite.com/us.mysite.com с прибиванием гвоздями поддоменов с ориджинами норм тема, если это аппка вроде таск трекера, но сомнительная тема, если это SEO история, ибо поисковик будет это видеть разными страницами. Ок, можно заморочиться, и апи коллы делать на ближайшие ориджин, если это SPA, но, все равно, статика будет тормозить.

    Приведу реальный пример, где очень хотели уйти от CF, но не смогли. Есть сетка SEO сайтов с миллионами страниц в индексе гугла. Трафик примерно поровну идёт с Африки (реальные посетители), и с США (бот гугла, обновляющий свой индекс). Принципиально важно быстро отдать и там и там (тормоза на гугле -> пессимизация в выдаче. Тормоза в Африке -> посетители не дожидаются открытия страницы и идут дальше по выдаче). Страницы SSR (так лучше для SEO). Манипуляции с редиректами хз, как себя покажут для SEO. Итого, держат 2 ориджина (1 Европа ради Африки, второй - США ради гугла), CF дополнительно гарантирует, что

    1) статика будет отдана с эджа

    2) кеш мисс не приведёт к пересечению океана