Cloudinary — хранение и автооптимизация картинок для сайта

Ты сделал в «Змейке» экран профиля с аватаркой пользователя. На телефоне она занимает сорок пикселей в углу экрана, на десктопе — сто двадцать в шапке страницы. Загружаешь пользователю одну и ту же картинку на оба устройства — и телефон честно скачивает лишние килобайты ради квадрата размером с ноготь. Можно, конечно, заранее нарезать три-четыре размера каждой картинки руками. А можно один раз загрузить оригинал в сервис, который сам подгонит его под любой экран по запросу. Второй вариант и называется Cloudinary — облачное хранилище картинок с автоматической подстройкой под устройство и раздачей через CDN, сеть серверов, расположенных ближе к пользователю, чем твой основной сервер.

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

Cloudinary — облачный сервис для хранения, обработки и раздачи изображений и видео. Идея простая: ты загружаешь картинку один раз, а дальше просишь у сервиса нужную версию прямо в ссылке — размер, формат, качество, обрезку — и Cloudinary отдаёт готовый файл, даже не заглядывая в твой код.

Работает это через специальный вид ссылки. У обычной картинки на сайте адрес прямой: файл лежит там, куда его положили, и выглядит всегда одинаково. У картинки в Cloudinary адрес превращается в маленькую программу: часть пути — это не имя папки, а инструкция «сделай ширину 300 пикселей, обрежь по центру, выбери сам подходящий формат». Меняешь эту часть ссылки — получаешь другую версию той же картинки, без повторной загрузки файла и без единой строчки кода обработки изображений в своём приложении.

Три вещи стоят за этой ссылкой:

• Хранилище. Оригинал картинки лежит в облаке Cloudinary один раз, независимо от того, сколько версий у него потом попросят.
• Обработка на лету. Сервер Cloudinary при первом запросе конкретной версии — скажем, «300×300, обрезка по лицу, формат WebP» — создаёт её из оригинала и запоминает результат.
• CDN. Готовую версию Cloudinary раздаёт через собственную сеть точек присутствия по всему миру, поэтому житель Владивостока и житель Калининграда получают картинку с ближайшего к ним сервера, а не с одного-единственного дата-центра.

Для новичка это выглядит как магия, но магии здесь нет — просто вся тяжёлая работа с картинками, которую иначе пришлось бы писать и поддерживать самому, вынесена в отдельный сервис с готовым API.

Чем Cloudinary отличается от S3-хранилища и Squoosh

В курсе уже разобраны два соседних инструмента, и с ними Cloudinary легко перепутать, если смотреть по верхам. Разница принципиальная, и её стоит проговорить явно.

S3-хранилище — это просто склад. Ты кладёшь туда файл, получаешь ссылку, а дальше файл лежит и отдаётся ровно таким, каким был загружен. Хочешь другой размер — либо создавай и загружай его отдельно, либо пиши свою серверную логику обработки картинок. S3 ничего не знает про содержимое файла: для него что аватарка, что архив с документами — просто набор байтов под именем.

Squoosh — инструмент из другого лагеря: разовое ручное сжатие. Ты открываешь картинку в браузере, крутишь ползунок качества, скачиваешь готовый файл и кладёшь его в проект. Это происходит один раз, до публикации, и дальше эта единственная сжатая версия обслуживает всех пользователей одинаково — и телефон, и широкий монитор.

Cloudinary объединяет хранение и обработку в один сервис и делает решающий шаг дальше: обработка происходит не один раз вручную, а автоматически, по запросу, под каждый конкретный показ. Разницу проще всего свести в одну формулу.

Смысл в одной фразе: S3 плюс Squoosh — это «сам храню и сам сжимаю один раз», а Cloudinary — «загрузил один раз, а сервис сам подстраивает картинку под каждый показ». Первый подход дешевле и проще для статичного сайта с горсткой картинок, которые никогда не меняются. Второй окупается там, где картинок много, показывают их на самых разных экранах и подгонка размера вручную превращается в отдельную постоянную работу.

Важно и то, что подходы не взаимоисключающие. Squoosh пригодится и с Cloudinary — например, чтобы сжать исходник перед первой загрузкой и не тратить лишнее место в бесплатном лимите. А S3 остаётся правильным выбором для файлов, которые вообще не нуждаются в трансформациях: документов, архивов, экспортов данных. Cloudinary же имеет смысл подключать именно там, где картинку показывают в разных размерах разным устройствам.

Как работает трансформация картинок по URL

Сама механика трансформации — самая необычная часть Cloudinary для новичка, поэтому стоит разобрать её по шагам.

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

Условно ссылка складывается из трёх частей: адрес твоего облака в Cloudinary, блок трансформаций и имя файла. Меняя средний блок, ты просишь другую версию той же самой картинки: другую ширину и высоту, другой способ обрезки, другой формат, другой уровень сжатия. Сервер не хранит все эти версии заранее — он создаёт нужную версию в момент первого запроса, а дальше отдаёт уже готовый результат из кэша и раздаёт его через CDN.

Процесс от загрузки до показа пользователю выглядит так:

flowchart TB
    A["Оригинал картинки загружен в Cloudinary"] --> B["Браузер запрашивает ссылку с параметрами"]
    B --> C["Cloudinary создаёт нужную версию из оригинала"]
    C --> D["Версия сохраняется в кэше CDN"]
    D --> E["Пользователь получает картинку с ближайшего узла"]

При повторном запросе той же комбинации параметров — скажем, ещё один пользователь с таким же размером экрана открыл ту же страницу — версия уже готова и лежит в кэше, поэтому Cloudinary отдаёт её мгновенно, без повторной обработки. Оригинал при этом никогда не трогается и не перезаписывается: сколько бы версий ни запросили, исходный файл остаётся неизменным, и в любой момент можно попросить у него совершенно новую комбинацию параметров.

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

Практический пример: аватарки и скриншоты «Змейки» под разные экраны

Разберём на конкретной задаче курса. У «Змейки» может быть страница профиля игрока с аватаркой и общая страница со скриншотами лучших партий. И то и другое — ровно тот случай, где Cloudinary раскрывается лучше, чем обычное хранилище.

Аватарка пользователя. Пользователь один раз загружает фото — например, квадрат 1200×1200 пикселей. Дальше эту же картинку нужно показать в нескольких местах: маленьким кружком 32×32 в списке лидеров, кружком побольше 64×64 в шапке страницы, крупно 200×200 на самой странице профиля. Без Cloudinary пришлось бы либо генерировать три файла при загрузке и хранить все три, либо каждый раз показывать полноразмерный оригинал и заставлять телефон скачивать мегабайт ради иконки размером с монету. С Cloudinary оригинал загружается один раз, а на каждой странице просто меняется блок параметров в ссылке — сервис сам обрежет квадрат, впишет нужный размер и подберёт формат под браузер посетителя.

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

Общий принцип: как только картинку одного пользователя нужно показывать больше чем в одном размере или больше чем на одном типе устройства, ручное сжатие через Squoosh начинает требовать по несколько версий на каждый случай, а обычное хранилище вроде S3 отдаёт то, что загрузили, без вариантов. Cloudinary снимает эту заботу целиком: одна загрузка, любое число версий по требованию.

Автоматический выбор формата и качества

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

Современные форматы вроде WebP и AVIF весят заметно меньше JPEG и PNG при похожем визуальном качестве, но поддержка форматов у браузеров разная: старый браузер может не понимать AVIF, а новый прекрасно с ним справляется. Раньше эту разницу приходилось разруливать вручную — определять браузер пользователя и подсовывать нужный формат кодом. Cloudinary умеет делать это автоматически: специальный параметр в ссылке говорит сервису «сам выбери оптимальный формат под браузер, который сейчас запрашивает картинку», и дальше один и тот же посетитель получает WebP или AVIF, если браузер их понимает, а тот, кто сидит со старым софтом, — обычный JPEG, и всё это без разветвлений в коде приложения.

Похожим образом работает автоматический подбор качества: вместо того чтобы вручную выставлять число в настройках сжатия, как это делается в Squoosh, можно попросить сервис самому найти баланс между весом файла и визуальным качеством для конкретной картинки. Итог тот же, что при ручной работе в Squoosh, — файл легче, а разница на глаз не видна, — но происходит это автоматически при каждом запросе, а не один раз руками перед публикацией.

Это ключевое отличие от подхода «сжал один раз в Squoosh»: там разработчик один раз вручную находит компромисс между весом и качеством для конкретного экрана и конкретного браузера того времени. В Cloudinary этот компромисс ищется заново при каждом запросе, под конкретного посетителя с его конкретным браузером — то есть решение подстраивается под аудиторию сайта, а не фиксируется навсегда в момент публикации.

Регистрация и первая загрузка

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

В личном кабинете доступны три ключевых значения для подключения через API: имя облака, API key и API secret. Имя облака открыто присутствует в любой ссылке на картинку и не является секретом. А вот API key и особенно API secret дают возможность загружать, менять и удалять файлы от твоего имени — обращаться с ними нужно так же осторожно, как с любым другим ключом доступа к платному сервису.

Первую картинку можно загрузить прямо из веб-интерфейса личного кабинета — перетащить файл мышкой и увидеть готовую ссылку. Это удобно, чтобы за минуту понять принцип работы сервиса и поиграть с параметрами трансформации, прежде чем подключать загрузку из своего приложения. Для реального проекта загрузка дальше идёт программно — через API, вызванный с сервера приложения или через специальный виджет загрузки, который можно встроить прямо в форму на странице.

Отдельного внимания заслуживает режим загрузки без ключей — так называемые unsigned upload presets. Это заранее настроенный в личном кабинете шаблон правил загрузки — например, «принимать только картинки, не больше пяти мегабайт, складывать в определённую папку», — который можно вызывать прямо из браузера пользователя, не передавая туда секретный ключ вовсе. Такой режим удобен именно для форм загрузки аватарки: пользователь выбирает файл, браузер сам отправляет его в Cloudinary по адресу пресета, а секретный ключ приложения при этом нигде не засвечивается.

Точную последовательность экранов и актуальный вид личного кабинета описывать здесь смысла нет — интерфейс сервиса со временем меняется, а официальная документация на сайте Cloudinary обновляется вместе с ним и всегда точнее любого снимка на конкретный момент.

Как подключить Cloudinary к проекту на Next.js

Для приложения на Next.js, на котором собран курс, у Cloudinary есть официальный npm-пакет с готовыми компонентами и функциями — не нужно собирать URL-строки с параметрами вручную и держать в голове синтаксис трансформаций.

Логика подключения укладывается в четыре шага, знакомые по любому другому облачному сервису курса.

Шаг 1. Заведи облако и ключи. Зарегистрируйся в Cloudinary, скопируй имя облака, API key и API secret из личного кабинета.

Шаг 2. Сохрани ключи в переменные окружения. Имя облака можно оставить открытым — оно и так видно в каждой ссылке на картинку. А вот API key и API secret идут в серверные переменные окружения, недоступные из кода, который выполняется в браузере пользователя.

Шаг 3. Настрой загрузку. Для формы, где пользователь сам выбирает файл — например, аватарку в профиле, — проще всего подойдёт unsigned upload preset: браузер отправляет файл прямо в Cloudinary, а серверу приложения останется только получить обратно готовую ссылку и сохранить её в базе данных рядом с пользователем. Для загрузок, которые инициирует сам сервер — скажем, сохранение сгенерированной картинки, — подписанный запрос с API key и secret идёт с сервера напрямую.

Шаг 4. Формируй ссылки с трансформациями там, где показываешь картинку. Официальный компонент для Next.js сам собирает нужную ссылку с параметрами по переданным ему ширине, высоте и способу обрезки — писать URL руками не придётся. Если пишешь приложение вместе с ИИ-ассистентом, задача формулируется просто: «подключи Cloudinary, аватарку пользователя показывай через официальный компонент с автоматическим форматом и нужным размером под каждый блок интерфейса» — ассистент подставит конкретный код под структуру проекта.

В базе данных, как и в случае с обычным объектным хранилищем, хранится не сама картинка, а текстовая ссылка на неё — или, если точнее, идентификатор картинки внутри облака, из которого при показе собирается ссылка с нужными параметрами. Логика та же: тяжёлые файлы живут вне базы, база хранит только короткую строку.

Если картинки для проекта создаются ИИ-генератором — например, обложки или иллюстрации через Nano Banana, — готовый результат генерации имеет смысл сразу загружать в Cloudinary, а не хранить локально в папке проекта: тогда одна сгенерированная картинка сама получит все нужные размеры под разные блоки интерфейса, без повторной ручной подготовки версий.

Где хранить ключ доступа Cloudinary

API key и API secret Cloudinary дают доступ к твоему облаку: тот, кто ими завладеет, сможет загружать, менять и удалять файлы от твоего имени, а в некоторых сценариях — расходовать оплаченные лимиты трансформаций и трафика. Обращаться с ними нужно с той же осторожностью, что и с ключом любого другого платного API.

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

Отдельно стоит запомнить: имя облака секретом не является и открыто видно в каждой ссылке на картинку — прятать его не нужно и незачем. А вот API secret нужно прятать так же строго, как пароль от личного кабинета, потому что фактически им и является.

Защита от чужого хотлинкинга и перерасхода лимитов

У Cloudinary, в отличие от простого хранилища файлов, есть особенность, о которой новички часто не думают заранее: каждая новая комбинация параметров трансформации — это отдельная операция обработки, которая расходует лимит сервиса. Если оставить трансформации полностью открытыми, ими может воспользоваться кто угодно, не только твоё приложение.

Два сценария злоупотребления встречаются чаще всего.

Чужой сайт вставляет твою ссылку у себя. Так называемый хотлинкинг: кто-то находит прямую ссылку на картинку в твоём облаке Cloudinary и вставляет её на собственной странице — чужие посетители грузят картинку с твоего аккаунта, а трафик и лимиты тратятся на тебя, хотя пользы твоему проекту от этого никакой.

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

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

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

Cloudinary или S3 плюс Squoosh: что выбрать

Прямого «правильного» ответа нет — выбор зависит от того, как картинки используются в конкретном проекте, а не от абстрактного превосходства одного подхода над другим.

Для «Змейки» на ранних этапах курса — логотип, иконка, пара статичных обложек — вполне достаточно того, что уже разобрано в статьях про S3-хранилище и Squoosh: такие картинки не меняются, их немного, и заранее сжатой версии хватает на все случаи. Cloudinary имеет смысл подключать в тот момент, когда в проекте появляются пользовательские аватарки, растущая галерея скриншотов или любой другой поток изображений, который нужно показывать по-разному на разных экранах без ручной подготовки версий под каждый случай.

Точные тарифы и текущие бесплатные лимиты трансформаций, хранения и трафика меняются и зависят от условий на момент регистрации — актуальные цифры смотри на сайте Cloudinary, а не в статьях, написанных заранее.

Частые ошибки при подключении Cloudinary

Ошибка 1. Хранить API secret в коде фронтенда

Если запрос к API Cloudinary с секретным ключом формируется в браузере, ключ виден любому, кто откроет консоль разработчика. Подписанные операции — загрузка, удаление, изменение — должны идти только с сервера или через unsigned preset без секретных данных.

Ошибка 2. Не ограничивать домены и трансформации

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

Ошибка 3. Генерировать URL с параметрами вручную построчно в разных местах кода

Если в каждом компоненте писать строку с параметрами трансформации отдельно, любая правка — например, смена способа обрезки — требует правок во всех местах разом. Официальный компонент или общая функция для сборки ссылок избавляют от этой возни и снижают риск опечатки в параметрах.

Ошибка 4. Загружать в Cloudinary файлы, которым автоматическая обработка не нужна

Документы, архивы, экспорты данных — такие файлы не выигрывают от трансформаций и умной раздачи картинок, а место в лимите Cloudinary при этом занимают. Для них по-прежнему подходит обычное объектное хранилище вроде S3.

Ошибка 5. Не проверять, что оригинал загружен в достаточном разрешении

Cloudinary умеет уменьшать картинку под любой размер, но не умеет придумывать пиксели, которых в оригинале не было. Если исходник загружен мелким, а трансформация просит крупную версию, результат будет размытым. Правило простое: оригинал всегда должен быть не меньше самой крупной версии, которую от него когда-либо попросят.

Чек-лист «Cloudinary готов к работе»

• Аккаунт зарегистрирован, имя облака, API key и API secret получены.
• API key и API secret хранятся в переменных окружения на сервере, а не в коде фронтенда.
• Для клиентской загрузки настроен unsigned upload preset с ограничением по типу и размеру файла.
• В личном кабинете ограничен список доменов, с которых разрешены запросы к картинкам.
• Список разрешённых трансформаций зафиксирован, произвольные параметры в ссылке отключены.
• В базе данных приложения хранится только ссылка или идентификатор картинки, не сам файл.
• Показ картинок в интерфейсе идёт через официальный компонент или общую функцию сборки ссылок.
• Автоматический выбор формата и качества включён для картинок, где это уместно.
• Оригиналы загружаются в разрешении не меньше самой крупной нужной версии.
• Проверены реальные ссылки с разными параметрами — размер, обрезка, формат — до подключения в продакшн.

Частые вопросы

Чем Cloudinary принципиально отличается от S3-хранилища?

S3 хранит файл таким, каким его загрузили, и отдаёт всегда одну и ту же версию. Cloudinary хранит оригинал один раз, а версии под конкретный размер, формат и способ обрезки создаёт на лету по параметрам прямо в ссылке — не нужно заранее готовить и хранить несколько копий одной картинки под разные экраны.

Нужен ли мне Cloudinary, если я уже сжимаю картинки в Squoosh?

Если картинок немного и они не меняются — логотип, иконки, пара статичных обложек, — сжатой один раз версии из Squoosh обычно достаточно. Cloudinary становится полезен, когда картинок много, их загружают сами пользователи или одну и ту же картинку нужно показывать в разных размерах на разных устройствах без ручной подготовки каждой версии.

Можно ли загружать картинки в Cloudinary прямо из браузера пользователя?

Да, через unsigned upload preset — заранее настроенный в личном кабинете шаблон правил загрузки, который не требует передавать секретный ключ в браузер. Загрузку с полным доступом через API key и secret стоит держать только на сервере.

Что будет, если оставить трансформации полностью открытыми?

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

Сколько стоит Cloudinary для небольшого проекта?

У сервиса есть бесплатный уровень, а дальше стоимость растёт вместе с объёмом хранения, трафика и числа обработок. Точные цифры и условия меняются — актуальные тарифы смотри на сайте Cloudinary.

Подходит ли Cloudinary для видео, а не только для картинок?

Да, сервис умеет работать и с видеофайлами по похожему принципу — хранение оригинала и трансформации на лету. Для курса и учебного проекта «Змейка» актуальнее именно картинки, но если в будущем понадобится похожая логика для видео, механика подключения и хранения ключей будет той же самой.

Заключение

Cloudinary закрывает задачу, с которой не справляются ни обычное объектное хранилище, ни разовое сжатие: показывать одну и ту же картинку в разных размерах и форматах под разные устройства без ручной подготовки версий заранее. Загружаешь оригинал один раз — а дальше сервис сам создаёт нужную версию по параметрам в ссылке и раздаёт её через CDN, ближайший к каждому конкретному пользователю.

Выбор между Cloudinary и связкой S3 плюс Squoosh — это выбор между «есть постоянный поток разноразмерных картинок» и «есть небольшой фиксированный набор файлов». Для аватарок и растущей галереи скриншотов «Змейки» первый вариант экономит время на подготовке версий вручную. Для логотипа и пары статичных обложек второй остаётся проще и дешевле. Как и с любым платным сервисом курса, главное — хранить ключи доступа в переменных окружения на сервере и с самого начала ограничить домены и трансформации, чтобы автоматизация работала на проект, а не превращалась в источник неожиданных расходов.