Ускоряем контент и API мобильных приложений с помощью CDN

Что вам нужно (и что CDN делает для приложения)

У вас есть мобильное приложение — iOS, Android или оба — которое во время работы скачивает изображения и медиа, возможно скачиваемые пакеты ресурсов, и общается с HTTP API за данными. И у вас есть аккаунт cdn.com.tr. Это вся настройка. CDN встаёт перед всем, что ваше приложение забирает по HTTP, и отдаёт это с edge рядом с пользователем, по HTTPS, поглощая нагрузку.

Сразу честная граница: сам бинарник приложения — .ipa или .apk, который вы публикуете, — распространяется App Store и Play Store по их собственным сетям, так что CDN этого не заменяет. CDN ускоряет всё, что приложение забирает во время работы: изображения, медиа, пакеты ресурсов, удалённую конфигурацию и ваш API. (Если вы также раздаёте сборки напрямую — корпоративный или сайдлоуд APK — их тоже можно отдавать с CDN-хранилища; см. руководство по распространению игр.)

Отдавайте изображения, медиа и пакеты ресурсов с edge

Самое объёмное, что скачивает приложение, — это контент: изображения профиля и товаров, миниатюры, аудио и видео, а также скачиваемые пакеты ресурсов или уровни. Разместите этот контент в CDN-хранилище (или за pull-CDN перед вашим существующим медиасервером), и приложение будет забирать каждый файл с ближайшего edge, а не с единственного источника, который может быть на другом континенте. Первый запуск и насыщенные контентом экраны загружаются быстро везде, а ваш источник перестаёт отдавать одно и то же изображение десять тысяч раз.

Как и при любом кэшировании на edge, версионируйте путь всего, что может измениться — /assets/v42/pack.bin или хеш сборки в URL — так, чтобы новая версия была новым URL, который никогда не устаревает, и кэшируйте версионированные файлы намертво. Контент, который действительно никогда не меняется, можно кэшировать на edge практически вечно.

Кэшируйте ответы вашего API на edge (там, где это безопасно)

Многое из того, что возвращает мобильный API, одинаково для каждого пользователя и меняется медленно: каталог, лента на главной, таблица лидеров, публичная конфигурация. Такие ответы можно кэшировать на edge с коротким TTL, так что десять тысяч открытий приложения за минуту сворачиваются в горстку запросов к источнику, а каждый пользователь всё равно получает ответ с ближайшего edge. Правило простое: кэшируйте то, что общее и медленно меняется, и никогда не кэшируйте то, что персонально.

Помечайте общие, кэшируемые ответы публичным Cache-Control с разумным max-age (или s-maxage для edge), а всё, что относится к конкретному пользователю или требует аутентификации, помечайте как private / no-store, чтобы это никогда не кэшировалось и не отдавалось не тому человеку. Когда исходные данные меняются, пуржите закэшированный путь, чтобы следующий запрос получил свежие данные. Эта комбинация даёт скорость edge на горячих общих эндпоинтах, никогда не утекая данными одного пользователя к другому.

Cache-Control: общие ответы и ответы для конкретного пользователя

# shared, slow-changing response (catalog, public config, feed)
Cache-Control: public, s-maxage=60, stale-while-revalidate=30

# per-user or authenticated response — never cache this
Cache-Control: private, no-store

Быстро доставляйте удалённую конфигурацию и feature flags

Большинство приложений при запуске забирают небольшой документ конфигурации или feature flags: что показать, в каком эксперименте находится пользователь, аварийные выключатели для сломанных функций. Разместите этот JSON на CDN с коротким кэшем. Поскольку он отдаётся с edge, каждое приложение быстро получает его при старте; а поскольку вы можете его пуржить, переключение флага или отключение сломанной функции происходит мгновенно для всей базы пользователей без выпуска обновления приложения.

Держите его маленьким и кэшируйте ненадолго (от десятков секунд до нескольких минут), чтобы изменение распространялось быстро, и пуржите при публикации, когда нужно, чтобы оно вступило в силу немедленно. Это самый безопасный рычаг для живого приложения: без ревью в сторе, без принудительного обновления — просто документ на edge, который можно менять по требованию.

remote-config.json, отдаваемый с CDN

{
  "min_supported_version": "3.2.0",
  "features": {
    "new_checkout": true,
    "live_events": false
  },
  "banner": { "enabled": true, "url": "https://cdn.yourapp.com/img/promo-v7.webp" }
}

Оптимизируйте изображения под экраны телефонов и мобильную сеть

У телефонов маленькие экраны и часто медленное, лимитированное соединение, поэтому отдавать им изображения десктопного размера — трата трафика и времени. Отдавайте современные форматы — WebP или AVIF — и подгоняйте размер изображений под устройство, а не отправляйте фото 3000px в слот 400px. Меньшие изображения нужного размера означают, что экраны отрисовываются быстрее, а пользователи на мобильной сети тратят меньше трафика, что напрямую улучшает ощущение отзывчивости приложения.

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

Защищайте API и справляйтесь со всплесками

Мобильный бэкенд получает удары волнами: релиз, push-уведомление, кампания или вирусный момент отправляют каждое приложение к вашему API одновременно — а мобильные клиенты усугубляют это, агрессивно повторяя запрос сразу после сбоя, превращая заминку в шторм. Кэширование на edge уже поглощает всплеск чтения на ваших общих эндпоинтах, так что поток одинаковых запросов обрабатывает сеть, а не ваш источник.

Помимо этого, поставьте перед вашим API CDN WAF и защиту от DDoS, добавьте rate limiting, чтобы ни один клиент или IP не мог заваливать логин, регистрацию или дорогой эндпоинт. Ваш настоящий источник остаётся скрытым за edge, так что и легитимный всплеск, и прямые атаки попадают на сеть, построенную для их поглощения. В результате приложение остаётся отзывчивым именно в тот день, когда это важнее всего.

Приложения, которые на это опираются