Bunny.net для статики: когда CDN даёт экономию, а когда только усложняет стек

Bunny.net для статики: когда CDN даёт экономию, а когда только усложняет стек

Если у вас картинки, CSS, JS, шрифты и лендинги без тяжёлой логики — Bunny.net обычно ставят как edge-слой поверх origin. Схема простая: сайт живёт на VPS/хостинге, а статика отдаётся с CDN. Это снижает нагрузку на сервер и часто улучшает TTFB для дальних географий, особенно если origin один и он не рядом с аудиторией.

Что проверить перед подключением:
— cache-control на origin: для статики нужен долгий TTL, иначе CDN будет постоянно ходить на сервер
— immutable для версионированных файлов: style.css?v=123 лучше, чем style.css без версии
— query strings: не все настройки кэша одинаково работают с параметрами
— Brotli и HTTP/2/3: включайте, если клиент и CDN это поддерживают
— origin shield или аналогичный защитный слой, если у вас много одинаковых запросов

Bunny.net особенно удобен, когда сайт нужно ускорить без миграции на новый хостинг: подключили pull zone, вынесли `/wp-content/`, `/assets/`, медиа и получили разгрузку. Но если у вас частые обновления без версионирования файлов, ошибки в заголовках кэша или много персонализированного контента, CDN начнёт мешать: пользователи будут видеть старые файлы, а вы — ловить «плавающие» баги.

Для статики правило одно: сначала наводите порядок в кэше и путях файлов, потом включаете CDN. Bunny.net хорошо работает там, где контент предсказуемый, а URL не меняются хаотично.