Настройка CDN для доставки контента мобильного приложения
Без CDN запрос за изображением профиля из Минска идёт на сервер в Амстердаме или Сингапуре — 80–150 мс только на RTT, без учёта времени ответа сервера. CDN кэширует контент на ближайшем к пользователю узле. Для мобильного приложения с медиаконтентом это разница между ощущением «быстрого» и «медленного» приложения.
Что через CDN, что нет
CDN имеет смысл для статического или редко меняющегося контента: изображения, аватарки, видео, PDF, OTA-обновления, обновления ресурсов игры (Addressables, Asset Bundles). API-запросы с динамическими данными через CDN не кэшируются в стандартной конфигурации — для них нужен API Gateway или Edge Functions.
Важный момент: персональные данные пользователей (документы, личные фото) через публичный CDN с длинным TTL — риск. Для таких файлов нужны Signed URLs с коротким временем жизни.
Выбор провайдера
| Провайдер | Сильные стороны | Когда выбираем |
|---|---|---|
| Cloudflare CDN | Бесплатный тариф, простая настройка, DDoS-защита | Стартап, ограниченный бюджет |
| AWS CloudFront | Нативная интеграция с S3, Lambda@Edge | Инфраструктура уже на AWS |
| Google Cloud CDN | Интеграция с GCS, GKE | Инфраструктура на GCP |
| BunnyCDN | Низкая цена, хорошая скорость в СНГ | Аудитория в СНГ, стоимость важна |
| Fastly | Edge computing, Varnish под капотом | Нужны сложные правила кэширования |
Для аудитории в России и СНГ стоит проверить наличие POP-узлов в Москве и Санкт-Петербурге — не все крупные CDN имеют их сейчас.
Настройка кэширования
Стратегия TTL зависит от типа контента:
-
Аватарки пользователей: короткий TTL (1–24 часа) + versioning через query string (
?v=hash) или путь (/avatars/v2/user-123.jpg) - Статические ресурсы приложения (иконки, фоны): длинный TTL (30–365 дней) + cache-busting через хэш в имени файла
- Видеоконтент: streaming через Range requests, TTL средний
Cache-Control: public, max-age=2592000, immutable — для ресурсов с хэшем в имени. immutable говорит браузеру и HTTP-клиенту не проверять свежесть до истечения max-age.
На стороне мобильного приложения: OkHttp на Android кэширует ответы если сервер отдаёт правильные заголовки. Настройка Cache с размером 50–100 МБ на диске + CacheControl при построении запросов позволяет работать оффлайн с закэшированным контентом.
На iOS: URLCache с diskCapacity 100 МБ. Для медиа — NSURLRequest.CachePolicy.returnCacheDataElseLoad.
Инвалидация и purge
CDN кэширует по URL. Изменение файла без изменения URL не приводит к обновлению кэша до истечения TTL. Три подхода:
-
Версионированные URL (
/assets/logo-a1b2c3d4.png) — лучший вариант, не требует ручного purge -
Query string версии (
/assets/logo.png?v=42) — проще, но некоторые CDN игнорируют query string при кэшировании (нужно явно включить) - Ручной purge через API — для срочных замен. Cloudflare, AWS CloudFront, BunnyCDN имеют API для этого, интегрируем в CI/CD pipeline
Мониторинг
После настройки смотрим:
- Cache Hit Ratio в дашборде CDN — целевое значение 90%+. Если ниже — TTL слишком короткий или много уникальных URL
- Bandwidth savings — сколько трафика обслуживает CDN против origin
- P95 латентность по регионам — убеждаемся, что целевые рынки получают ускорение
В мобильном приложении логируем X-Cache заголовок ответа (если CDN его отдаёт) в аналитику — позволяет видеть реальный hit rate с точки зрения клиента.
Сроки настройки: один-два рабочих дня для базовой конфигурации. Сложные правила (Edge Functions, geo-routing, Signed URLs) — три-пять дней.