Static sharding и умный DNS: ускоряем статику без боли

Static sharding — один из тех приёмов оптимизации, который часто всплывает в старых статьях и аудите производительности: «вынесите статику на несколько поддоменов, чтобы увеличить количество одновременных соединений». В 2025 году это звучит как архаика, но на практике тема до сих пор всплывает у админов и разработчиков, особенно на проектах с наследием.

Давайте разберёмся, как static sharding связан с DNS и CDN, как вообще работает этот паттерн, почему он почти везде потерял актуальность — и в каких нишевых сценариях всё ещё может быть полезен.

Что такое static sharding простыми словами

Исторически браузеры ограничивали число одновременных HTTP‑соединений на один хост (домен + порт). Типичные значения были 4–6 соединений. Если на странице сотни картинок, CSS и JS, всё это становилось «бутылочным горлышком».

Идея static sharding:

• взять статику (картинки, CSS, JS, шрифты);
• раскидать её по нескольким поддоменам вроде static1.example.com, static2.example.com, img.example.com;
• в HTML подставлять разные хосты, чтобы браузер создавал больше параллельных соединений и загружал ресурсы быстрее.

Связка с DNS здесь очевидна: каждый поддомен вынесен в отдельные A/AAAA/CNAME‑записи, а дальше уже веб‑сервер или CDN отдают статику.

В эпоху HTTP/1.1 это часто давало реальный выигрыш в загрузке крупного проекта. Сегодня, с HTTP/2 и HTTP/3, подход резко потерял актуальность — но всё ещё встречается из‑за исторических причин или неверных рекомендаций.

Почему static sharding завязан на DNS

Static sharding невозможно сделать без манипуляций с DNS. Минимальный набор действий:

• создать поддомены для статики;
• добавить DNS‑записи (обычно A/AAAA или CNAME) для каждого поддомена;
• настроить веб‑сервер или CDN так, чтобы эти имена обслуживали один и тот же пул статики (или разные наборы файлов по шард‑логике).

Классическая схема выглядела так:

; основной сайт
www.example.com.  300  IN  A     203.0.113.10

; шард №1 для статики
static1.example.com. 300 IN CNAME cdn.example.net.

; шард №2 для статики
static2.example.com. 300 IN CNAME cdn.example.net.

DNS здесь решает несколько задач:

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

Последний пункт важен: если вы ошибётесь в дизайне шардов, можно случайно убить эффективность кэша или, наоборот, сделать ненужное дублирование.

Static sharding, HTTP/2 и HTTP/3: почему чаще всего не нужно

Главный аргумент против static sharding сегодня — эволюция протоколов:

• HTTP/2 умеет мультиплексировать десятки и сотни запросов по одному TCP‑соединению;
• HTTP/3 делает то же самое поверх QUIC/UDP, дополнительно уменьшая влияние потерь пакетов;
• современные браузеры оптимизируют приоритеты загрузки ресурсов.

Во времена HTTP/1.1 шардирование позволяло обойти лимит в условные 6 соединений и загружать больше ресурсов параллельно. С HTTP/2/3 это превращается в анти‑паттерн:

• браузеру приходится открывать несколько TLS‑соединений к разным хостам;
• увеличиваются накладные расходы TLS‑рукопожатий;
• теряется часть преимуществ мультиплексирования по одному коннекту.

Отдельный минус: каждый новый хост — это дополнительный DNS‑lookup, который стоит времени, особенно на мобильных сетях.

Если у вас уже есть HTTP/2/3 между браузером и CDN или сервером, в подавляющем большинстве случаев sharding статики по поддоменам даёт ноль или даже ухудшает производительность.

Поэтому в современных гайдах по оптимизации производительности обычно рекомендуют:

• использовать один домен или поддомен для всей статики (например, static.example.com);
• или свести число хостов к минимально необходимому.

Где static sharding ещё может быть полезен

Тем не менее есть сценарии, где static sharding всё ещё встречается и может иметь смысл.

1. Наследие и долгий переход на HTTP/2/3

Если вы обслуживаете старую инфраструктуру:

• между CDN и конечным пользователем до сих пор только HTTP/1.1;
• или есть существенная доля старых браузеров и устройств, не поддерживающих HTTP/2;
• или ваш CDN в определённых регионах работает по старым схемам;

— тогда аккуратное шардирование статики по 2–3 поддоменам может дать выигрыш в TTFB и fully loaded time. Но это нужно измерять, а не просто включать «по привычке».

2. Логическое и операционное разделение

Иногда причина не в скорости, а в архитектуре:

• разделить пользовательский контент (загруженные файлы) и product‑статику по разным доменам;
• мигрировать часть статики на другой CDN поэтапно;
• разделить SLA и политику кэширования для разных типов ресурсов.

Пример схемы:

• assets.example.com — версии CSS/JS приложения с агрессивным кэшированием;
• media.example.com — пользовательские загрузки с более мягкими правилами;
• img.example.com — отдаётся из отдельного image‑proxy или ресайзера.

Формально это тоже static sharding (несколько хостов для статики), но мотив не в лимитах соединений, а в управляемости и безопасности.

3. Обход ограничений конкретного CDN или балансировщика

Редкий, но реальный кейс: какой‑то CDN‑провайдер или балансировщик имеет лимиты на количество запросов или соединений на хост. Тогда статику действительно иногда размазывают по нескольким хостам, чтобы распределить нагрузку.

Но и здесь это спорное решение: лучше сменить провайдера или тариф, чем завязывать архитектуру фронтенда на искусственные ограничения.

Static sharding и кэш браузера

Каждый хост в браузере имеет своё пространство кэша. Это значит:

• одна и та же картинка, доступная как https://static1.example.com/logo.png и https://static2.example.com/logo.png, будет кэшироваться дважды;
• при смене схемы шардинга (например, изменили алгоритм распределения) пользователи могут заново скачать большой объём статики, хотя у них уже есть те же файлы в кэше, но под другими хостами.

Это приводит к ненужному трафику и медленным «холодным» загрузкам после релизов.

Оптимальная стратегия для современных проектов:

• один стабильный поддомен для статики (например, static.example.com);
• версионирование файлов через имя (hash в пути: main.3f4a2c9.js);
• долгий Cache-Control: max-age=31536000, immutable для таких версионированных ресурсов;
• минимизация числа хостов, чтобы браузеру было проще переиспользовать кэш и соединения.

Static sharding и CDN

При использовании CDN часто возникает соблазн: «А давайте сделаем несколько CNAME на один и тот же CDN, чтобы шардировать статику». На практике получаем:

• несколько пространств кэша на стороне CDN (по разным хостам);
• хуже hit‑ratio, больше origin‑трафика;
• сложнее управлять правилами кэширования и защищать origin.

Этот подход имеет смысл только если CDN сам рекомендует подобную схему и умеет объединять кэш по хостам или давать отдельные преимущества per‑host (например, разные POP‑группы, разные WAF‑политики).

Чаще всего сейчас рекомендуют противоположное:

• один CNAME вида static.example.com CNAME myproject.cdnvendor.net;
• вся статика крутится через один hostname CDN;
• минимум лишних DNS‑записей и путаницы.

Если вы только выбираете инфраструктуру под фронтенд, разумно заранее продумать, как статика будет жить на тарифах виртуального хостинга или на отдельном облачном VDS, и сразу заложить простую схему с одним статическим доменом и CDN.

DNS‑аспекты static sharding: TTL, отказоустойчивость, геораспределение

Если вы всё же используете несколько поддоменов для статики, нужно аккуратно продумать DNS‑настройки.

TTL для статических поддоменов

Основная дилемма:

• маленький TTL (например, 60–300 секунд) — быстрее менять направление трафика при авариях и миграциях;
• большой TTL (например, 3600–86400 секунд) — меньше нагрузка на DNS и потенциально быстрее резолвинг для пользователей.

Для статических поддоменов обычно:

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

Поэтому TTL можно держать длиннее, чем для A‑записей основного сайта. При этом стоит учесть сценарии аварий: если origin меняется часто, а вы используете прямые A/AAAA‑записи без проксирующего CDN, то слишком большой TTL делает переключение на резерв длинным и болезненным.

Multi‑A и GeoDNS для статики

Один из современных вариантов «шардинга» без изменения хостов — использование:

• нескольких A/AAAA‑записей для одного поддомена (multi‑A);
• или GeoDNS (разные ответы в зависимости от региона клиента).

С точки зрения приложения это всё тот же static.example.com, а с точки зрения DNS и сети:

• запросы разлетаются по нескольким IP‑адресам (балансировка по кругу или иная логика);
• пользователи из разных регионов получают ближайший POP или дата‑центр.

Важно: это не static sharding в классическом смысле (несколько доменов), но решает ту же задачу распределения нагрузки и улучшения скорости без накладных расходов множества хостов и соединений.

Если вы проектируете глобальную инфраструктуру или переезд на CDN с использованием GeoDNS, имеет смысл заранее протестировать, как ваш DNS‑провайдер обрабатывает многозаписные ответы и геораспределение, и зафиксировать эту схему в документации.

Практические рекомендации: когда и как трогать существующий static sharding

Отдельная боль девопсов и админов — проекты, где static sharding уже реализован, а нужно понять, что с этим делать дальше.

Шаг 1. Замеряем, а не гадаем

Минимальный набор метрик, на который стоит посмотреть:

• включён ли HTTP/2/3 между браузером и CDN или сервером;
• количество одновременных соединений с браузера на хост (можно видеть в devtools);
• время DNS‑lookup для статических поддоменов;
• hit‑ratio CDN (если используется) по каждому поддомену;
• процент трафика на старые браузеры, не поддерживающие HTTP/2.

Если у вас:

• HTTP/2/3 включён для подавляющего большинства трафика;
• существенной выгоды по времени загрузки при шардировании нет;
• а конфигурация DNS и CDN усложнена из‑за множества хостов;

— то есть смысл планировать отказ от static sharding.

Шаг 2. План де‑шардинга статики

Аккуратный переход можно сделать так:

1. Выбрать целевой домен для статики, чаще всего один: static.example.com.
2. Убедиться, что этот домен корректно настроен в DNS, CDN и на веб‑сервере.
3. В приложении, шаблонах и фронтенд‑бандле заменить генерацию URL с множества хостов на единый.
4. Выпустить релиз с новой схемой URL, не трогая старые поддомены.
5. Наблюдать трафик: новые пользователи будут брать статику с static.example.com, старые — постепенно «выгорят» по кэшу и TTL.
6. Через несколько недель или месяц оценить остаточный трафик на старые шард‑домены и либо оставить для очень медленного «умирания», либо аккуратно редиректить (с учётом Cache-Control и выстраивания 301).

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

Шаг 3. Наведение порядка в DNS

После де‑шардинга стоит:

• проверить зону на «мусорные» записи старых статических поддоменов;
• удалить или перевести их в отдельную legacy‑зону, если такое используется;
• привести TTL к единой политике (например, 3600 секунд для статики и 300 секунд для критичных A‑записей приложений);
• задокументировать схему: какие поддомены используются для статики, какие — для API, какие — для пользовательских загрузок.

Типичные ошибки при static sharding

Список грабель, с которыми регулярно сталкиваются команды.

Ошибка 1. Случайное дублирование контента по разным хостам

Когда приложение выбирает шард случайно (например, по Math.random() в JavaScript), один и тот же ресурс может оказаться то на static1, то на static2. Это:

• убивает кэш браузера;
• может ломать CORS (особенно для шрифтов и XHR‑запросов);
• усложняет отладку.

Если уж шардировать, алгоритм должен быть детерминированным (например, по хешу пути) и стабильным.

Ошибка 2. Static sharding и cookies

Одна из исторических причин выносить статику на отдельный домен была в том, чтобы не отправлять куки сайта при запросе каждого CSS, JS или PNG. Но это работает только если:

• статический домен не входит в область действия куки;
• и вы не ставите куки на .example.com, если статика тоже на поддоменах *.example.com.

На практике часто делают так:

• куки висят на .example.com;
• статика — static1.example.com, static2.example.com;
• все куки продолжают улетать к каждому статическому запросу.

Правильный путь, если это реально актуально для ваших объёмов трафика, — вынести статику на отдельный домен второго уровня (например, example-static.net) и грамотно настроить CORS и политики безопасности. Но такой шаг усложняет инфраструктуру и должен быть обоснован цифрами.

Ошибка 3. Несогласованные TTL и миграции

Классическая ситуация: на static‑поддомены выставили огромный TTL (24 часа и больше), а потом резко меняют инфраструктуру CDN или origin. В итоге:

• часть пользователей ещё сутки ходит на старые IP;
• возникают «мистические» баги: недоступные ресурсы, битые картинки;
• сложно собрать консистентный отчёт по метрикам.

Если вы знаете, что в ближайшее время возможны миграции, TTL лучше временно снизить заранее и только потом крутить IP или целевой CNAME.

Итоги: какая стратегия статики и DNS оптимальна сегодня

Если обобщить всё вышесказанное, получится довольно простой чек‑лист.

• HTTP/2/3 везде, где это возможно. Максимальный приоритет — включить современные протоколы между браузером и вашим фронтом (CDN или веб‑сервером).
• Минимизируйте количество хостов. Один домен для приложения и один для статики (или даже один на всё, если куки и безопасность позволяют) чаще всего лучше, чем зоопарк static1..staticN.
• Версионируйте файлы по имени, а не по домену. Hash в пути плюс долгий Cache-Control работают лучше, чем пляски с поддоменами и «перекладывание» статики между ними.
• Используйте CDN и или GeoDNS для реального ускорения по миру. Это куда эффективнее, чем шардить статику по 3–4 поддоменам на одном и том же IP.
• Не бойтесь вычищать исторический static sharding. Но делайте это постепенно: сначала выравниваем схему URL, затем, через время, чистим DNS.

Static sharding как обход лимитов соединений в эпоху HTTP/1.1 можно смело считать почти мёртвым паттерном. Но темы DNS, кэша и CDN, стоящие за ним, остаются критически важными. Чем аккуратнее вы проектируете доменную схему и политику кэширования для статики, тем меньше сюрпризов при росте нагрузки и миграциях инфраструктуры.

Если у вас в проекте до сих пор живёт «зоопарк» статических поддоменов, имеет смысл однажды сесть, нарисовать текущую схему DNS и пути статики — и решить, что можно упростить. Часто такой рефакторинг даёт заметный выигрыш не только в скорости, но и в сопровождаемости проекта.