Если у вас статичный сайт на Astro с несколькими десятками изображений - скорее всего, хватит встроенной оптимизации Astro Assets, и платить за отдельный сервис не нужно. Если изображений тысячи, они приходят из разных источников и требуют разных размеров под разные страницы - выгоднее вынести это в Cloudflare Images или imgix. Разница в деньгах и во времени разработки ощутима уже на втором десятке посадочных страниц.
В проектах на Astro и Next.js мы регулярно видим одну и ту же ошибку: команда выносит картинки во внешний сервис «на всякий случай», хотя на сайте 30 изображений и они не меняются месяцами. И обратную ошибку: пытаются вручную генерировать пять размеров под каждую картинку при каждой сборке, хотя один пакет Cloudflare Images с on-the-fly трансформацией решил бы задачу за час настройки. Дальше - честное сравнение трёх подходов по деньгам, интеграции со стеком и реальным сценариям, без вендорского перекоса в чью-либо сторону.
Команды часто уже сократили JavaScript, включили сжатие и настроили кеширование, но страница всё равно грузится медленно - потому что изображения остаются самой тяжёлой частью большинства сайтов. Неправильный выбор здесь работает в обе стороны: внешний image CDN на маленьком сайте - это лишняя строка в бюджете и лишняя точка отказа, а отсутствие CDN на сайте с тысячами товарных фото - это ручная генерация размеров, забитый сборочный процесс и разъезжающиеся форматы между окружениями.
Image CDN: сервис, который отдаёт изображения через CDN и на лету меняет их размер, формат и качество по параметрам в URL - без того, чтобы вы заранее готовили и хранили десятки версий каждой картинки.
Коротко: для сайта с постоянным набором изображений (лендинг, блог, каталог до пары сотен товаров) обычно хватает Astro Assets или next/image - оптимизация происходит на этапе сборки, без внешнего сервиса. Если вы уже на Cloudflare и изображений много - берите Cloudflare Images за предсказуемую цену и простую интеграцию. Если нужна тонкая настройка трансформаций, работа с большой медиатекой или DAM-системой (централизованным хранилищем медиафайлов) - смотрите в сторону imgix.
Что вообще делает image CDN
Обычный хостинг картинок отдаёт файл как есть: тот же формат, тот же размер, независимо от того, кто и с какого устройства его запрашивает. Image CDN добавляет слой трансформации поверх раздачи.
При запросе вида /photo.jpg?w=800&fm=avif&q=70 сервис на лету меняет ширину, конвертирует формат и пересчитывает качество, а результат кеширует на edge-серверах CDN. Следующий запрос с теми же параметрами отдаётся уже из кеша, без повторной обработки.
Это закрывает три задачи одновременно:
- Адаптивные размеры. Одна исходная картинка отдаёт нужную ширину под мобильный, планшет и десктоп через
srcset, без ручной генерации версий. - Современные форматы. AVIF и WebP отдаются автоматически там, где браузер их поддерживает, с откатом на JPEG для старых клиентов.
- Единая точка хранения. Исходники лежат в одном месте (бакет, DAM, CMS), а все производные версии генерируются по запросу, а не хранятся заранее.
Альтернатива - встроенная оптимизация фреймворка (Astro Assets, next/image), которая делает то же самое, но на этапе сборки или через собственный serverless-обработчик, без стороннего сервиса и его биллинга.
Сравнение по ключевым параметрам
Прямое сравнение имеет смысл только по параметрам, которые реально влияют на решение: деньги, лимиты и то, насколько быстро сервис встаёт в существующий стек.
| Параметр | Cloudflare Images | imgix | Astro Assets / next/image |
|---|---|---|---|
| Модель цены | За хранимое + отданное изображение | За количество исходных (origin) изображений и трафик | Бесплатно, часть фреймворка |
| Бесплатный тариф | Есть, с лимитом по количеству изображений | Есть, с лимитом по origin-изображениям и запросам | Без лимитов - ограничение только в вашей инфраструктуре сборки |
| AVIF / WebP | Да, автоматически по Accept-заголовку | Да, автоматически по Accept-заголовку | Да, через Sharp на этапе сборки (Astro) или через встроенный image-оптимизатор (Next.js) |
| On-the-fly трансформации | Да, через параметры URL | Да, широкий набор параметров: обрезка, фокальные точки, водяные знаки | Нет - только то, что задано в коде на этапе сборки/рендера |
| Интеграция с Astro / Next.js | Через astro:assets remote-loader или ручной <img> | Через официальный или community-loader | Нативная, из коробки |
| CDN-покрытие | Сеть Cloudflare, одна из крупнейших в мире | Собственная edge-сеть на нескольких провайдерах | Зависит от хостинга сайта (Railway, Vercel, Netlify и так далее) |
| Когда неудобно | Слабее точечная настройка трансформаций, чем у imgix | Дороже при большом трафике без переговоров по тарифу | Не годится для пользовательской загрузки и часто меняющихся исходников за пределами репозитория |
Тарифы у Cloudflare Images и imgix начинаются с бесплатного или пробного уровня с лимитом по количеству изображений или запросов - точные цифры на конкретный момент проверяйте на сайте поставщика, они периодически пересматриваются.
Когда выбирать Cloudflare Images
Cloudflare Images имеет смысл, если сайт уже стоит на Cloudflare - как DNS, прокси или Pages/Workers - и вы хотите один биллинг вместо разрозненных сервисов.
Цена здесь предсказуема: платите за количество хранимых изображений и за количество уникальных трансформаций, без сюрпризов от трафика в пиковые дни, потому что CDN-раздача уже включена в тот же контур. Настройка занимает часы, а не дни - Worker или простой <img src> с параметрами в URL, без отдельной клиентской библиотеки.
Берите Cloudflare Images, когда:
- сайт уже на Cloudflare (Pages, Workers, просто proxied DNS);
- изображений от нескольких сотен и они регулярно обновляются (каталог, галерея, блог с частыми публикациями);
- важна предсказуемая единая цена, а не тонкая настройка каждой трансформации.
Если команде нужно встроить такой слой в уже работающий сайт без полного передела архитектуры, это обычно задача на доработку существующего сайта - добавление нового модуля, а не перестройка проекта с нуля.
Когда выбирать imgix
imgix закрывает случаи, где Cloudflare Images и встроенная оптимизация фреймворка упираются в потолок гибкости.
У imgix один из самых широких наборов параметров трансформации на рынке: фокальные точки для умного кропа, наложение водяных знаков, работа с PDF и видео-превью, поддержка внешних источников хранения (S3, Google Cloud Storage, DAM-системы вроде Bynder или Cloudinary DAM). Это тот случай, когда маркетинг или e-commerce команда сама управляет медиатекой в отдельной системе, а сайт лишь на лету запрашивает нужный кроп.
Берите imgix, когда:
- у компании уже есть DAM или большая медиатека вне репозитория сайта (тысячи товарных фото, баннеров под разные кампании);
- нужны нестандартные трансформации - умный кроп по лицам, водяные знаки, генерация превью из PDF;
- сайт не привязан к Cloudflare и смена инфраструктуры под это нецелесообразна.
Минус - стоимость растёт быстрее при большом трафике без индивидуальных условий, и для сайта с парой сотен изображений это избыточная гибкость, за которую всё равно платите.
Когда достаточно встроенной оптимизации Astro Assets
Встроенная оптимизация - это astro:assets в Astro или next/image в Next.js. Она решает ту же задачу форматов и размеров, но без внешнего сервиса и без счёта в другой платёжной системе.
Astro Assets на этапе сборки прогоняет изображения через Sharp, генерирует AVIF/WebP и нужные размеры под srcset, и складывает результат в статику. Next.js Image делает похожее, но может работать и в рантайме через собственный image-оптимизатор на сервере.
Этого достаточно, когда:
- сайт статичный или почти статичный - лендинг, блог, портфолио, корпоративный сайт до пары сотен изображений;
- набор картинок меняется редко и живёт в репозитории или CMS с привычным пайплайном публикации;
- нет задачи отдавать один и тот же исходник в сильно разных кропах для разных клиентов (веб, приложение, партнёрские виджеты).
Граница простая: как только изображения перестают помещаться в репозиторий или начинают приходить из внешних источников на лету (пользовательская загрузка, интеграция с внешним каталогом), встроенная оптимизация упирается в лимиты сборки, и разговор возвращается к CDN-слою. Если на сайте уже проседает LCP из-за конкретно формата и приоритета загрузки картинок, а не из-за архитектуры раздачи - это отдельная задача, которую мы разбирали в статье про оптимизацию LCP через AVIF, WebP и srcset. Там речь о технике сжатия и приоритета одного изображения, здесь - о том, откуда и как оно вообще раздаётся.
Что меняется после смены подхода на реальном кейсе
Показательный сценарий - сайт услуг с рекламным трафиком: около 15 посадочных страниц, на каждой по 20-40 изображений в hero-блоках, галереях кейсов и отзывах.
До перехода на image CDN исходники хранились в разных разрешениях, часть в JPEG без сжатия, srcset не был настроен. По нашим наблюдениям на подобных проектах суммарный вес страницы в таких условиях обычно держится в диапазоне 3-4 МБ, а LCP - в районе 4-4.5 секунды на мобильном 4G.
После переноса раздачи изображений на Cloudflare Images с автоматическим AVIF/WebP и адаптивными размерами вес страницы на подобных проектах обычно снижается до 1-1.5 МБ, а LCP - до 2-2.3 секунды. Конкретные цифры зависят от исходного качества фото и структуры страницы, но порядок улучшения именно такой - в 2-3 раза по весу и вдвое по LCP, без изменения самого дизайна.
При этом отдельная работа с приоритетом загрузки (fetchpriority, устранение loading="lazy" на hero-изображении) даёт дополнительный выигрыш поверх смены CDN-слоя - это уже вопрос техники, а не инфраструктуры.
Для кого это актуально
Выбор актуален для команд, которые строят сайт на Astro, Next.js или похожем стеке и уже упёрлись в вес изображений как в узкое место производительности - маркетинговые агентства, e-commerce с растущим каталогом, SaaS с блогом и медиатекой скриншотов продукта. Для одностраничника с десятком картинок эта статья скорее подтвердит, что внешний сервис пока не нужен, чем подтолкнёт его подключать.
Часто задаваемые вопросы
Можно ли использовать Cloudflare Images без остального стека Cloudflare? Технически да - можно подключить только Cloudflare Images как отдельный сервис, не переводя DNS или хостинг на Cloudflare. Но тогда часть преимущества (единый биллинг, общая CDN-сеть с остальным трафиком сайта) пропадает, и решение по деньгам стоит сравнивать с imgix на равных условиях. Если сайт стоит на Vercel, Netlify или Railway и переезд на Cloudflare не планируется, разница в удобстве между Cloudflare Images и imgix в этом сценарии почти стирается - выбор сводится к цене и набору нужных трансформаций.
Работает ли imgix с Astro из коробки?
Официальной интеграции уровня astro:assets у imgix нет, но подключение сводится к формированию URL с нужными параметрами трансформации и обычному <img> или <Image> компоненту поверх него. Это чуть больше ручной работы, чем нативный Astro Assets, но без ограничений на источник исходников. На практике достаточно написать небольшую вспомогательную функцию, которая собирает URL с параметрами ширины, формата и качества, и переиспользовать её во всех компонентах с изображениями по сайту.
Что выбрать для маленького лендинга на 10-15 изображений?
Встроенную оптимизацию Astro Assets или next/image. Подключать внешний image CDN ради полутора десятков картинок обычно не окупается ни по деньгам, ни по времени настройки - выигрыш в скорости будет минимальным по сравнению с уже сжатыми на сборке AVIF/WebP. Внешний сервис на этом объёме стоит рассматривать только если вы заранее знаете, что медиатека вырастет в разы за ближайшие месяцы, и не хотите потом переделывать раздачу изображений на ходу.
Нужен ли image CDN, если я уже использую Astro Image для сжатия? Если изображения статичные и живут в репозитории - нет, Astro Assets уже закрывает форматы и размеры. CDN-слой имеет смысл добавлять, когда изображения начинают приходить динамически: из CMS, от пользователей или из внешнего каталога, куда сборочный процесс Astro не дотягивается. Смешанный вариант тоже возможен - часть картинок (логотипы, иконки, статичные баннеры) остаётся на Astro Assets, а динамический контент уходит на внешний сервис.
Как понять, что текущая раздача изображений тормозит сайт? Проверьте вкладку Network в DevTools на самой тяжёлой странице и раздел LCP element в PageSpeed Insights или Lighthouse. Если самое тяжёлое изображение больше 200-300 КБ после сжатия или не отдаётся в AVIF/WebP там, где браузер это поддерживает - смена подхода к раздаче, скорее всего, окупится. Дополнительный сигнал - если разработчики вручную готовят несколько версий каждой картинки перед загрузкой на сайт: это верный признак, что процесс пора автоматизировать через CDN-слой или встроенную оптимизацию фреймворка.
Итог
Встроенная оптимизация Astro Assets и next/image закрывает большинство сайтов без единой лишней строки в счёте. Внешний image CDN нужен, когда изображений становится много, они приходят из разных источников или требуют трансформаций, которые сборка фреймворка сделать не может - тогда выбор идёт между предсказуемой ценой Cloudflare Images и гибкостью imgix.
Если на вашем сайте картинки уже стали узким местом по скорости или медиатека вышла за рамки того, что тянет сборка фреймворка - опишите архитектуру и объём медиатеки команде Exceltic.dev. Разберём текущую раздачу изображений и посчитаем, что даст ускорение через смену подхода к CDN, а что закроется точечной доработкой.