Логотип на лендинге весит 800 КБ и мылится на ретине. Иконка соцсети в футере — JPG с белым прямоугольником вокруг. Фотография героя — PNG на 4 МБ, потому что «так экспортнул дизайнер». Скриншот интерфейса в блоге — WebP, который не открывается в превью почты.
Это не выдуманные случаи. Это то, что находится на ревью почти каждого второго сайта, который к нам приходит. И почти всегда проблема не в дизайне и не во вкусе — проблема в том, что кто-то один раз нажал «Export as…» и не задумался, что именно он экспортирует и куда это пойдёт.
Формат экспорта — это не технический нюанс на десерт. Это решение, которое определяет, как быстро грузится страница, как она выглядит на разных экранах, как её видит поиск, и сколько денег уходит на CDN. Ошибка в формате не валит сайт целиком — она его медленно душит.
Почему это вообще важно
Картинки — это 60-70% веса среднего сайта. Не скрипты, не шрифты, не CSS. Картинки. И если на сайте 40 изображений, и каждое весит лишних 200 КБ из-за неправильного формата — это 8 МБ, которые пользователь скачивает без нужды.
На офисном вайфае это незаметно. На мобильном интернете в метро — это разница между «работает» и «закрыл вкладку».
Дальше эффект каскадный:
- Lighthouse и Core Web Vitals падают, потому что LCP растёт
- Поиск это видит и ранжирует сайт ниже
- CDN-счёт растёт пропорционально лишнему весу
- На слабых устройствах страница начинает дёргаться при скролле, потому что браузер пытается декодировать огромные растры
И всё это — из-за того, что иконку сохранили как PNG вместо SVG, а фото — как PNG вместо WebP.
Три формата, три задачи
Если упростить до уровня, на котором этим можно пользоваться каждый день:
- SVG — для всего, что нарисовано: логотипы, иконки, иллюстрации, графики.
- WebP (или AVIF) — для всего, что снято: фотографии, скриншоты с фотореалистичным содержимым, hero-баннеры.
- PNG — для редких случаев, когда нужна растровая графика с прозрачностью и WebP по какой-то причине не подходит (старая почта, экспорт в стороннюю систему, превью для соцсетей).
JPG в этой схеме почти не нужен. Он остался как совместимый дефолт, но WebP делает то же самое лучше при том же качестве.
Звучит просто. На практике 80% проблем — это именно нарушение этой базовой раскладки.
Антипаттерн: «PNG для всего»
Самый частый сценарий. Дизайнер экспортирует из Figma всё подряд в PNG, потому что это дефолт и «всегда работает». В итоге:
- Логотип весит 400 КБ вместо 4 КБ
- На ретине логотип мылится, потому что экспортировали в 1x
- Фото героя — 3 МБ PNG вместо 250 КБ WebP
- Иконки в интерфейсе — отдельные PNG-файлы вместо одного SVG-спрайта или иконочного шрифта
Лечится это не «переэкспортом всего». Лечится договорённостью на этапе передачи: что чем должно быть.
Антипаттерн: «SVG для фото»
Реже, но встречается. Кто-то слышал, что SVG — это «масштабируется без потерь», и пытается засунуть туда фотографию, обведённую трассировкой, или скриншот, конвертированный в base64 внутри SVG. Файл получается в 5-10 раз тяжелее WebP, рендерится медленно, и при увеличении видны артефакты трассировки.
SVG — для векторов. Если у объекта есть тени, градиенты со сложными переходами, фактуры — это уже не вектор, и SVG будет проигрывать растру.
Сценарий: иконки в интерфейсе
Самое частое место, где ломается формат. Разберём по шагам.
Плохо:
- Каждая иконка — отдельный PNG в 2-3 размерах (1x, 2x, 3x)
- Цвет иконки зашит в файл — чтобы перекрасить, нужно делать новый экспорт
- При hover меняется не цвет, а целая картинка
Хорошо:
- Иконки — SVG, либо инлайн в HTML, либо через из спрайта
- Цвет управляется через currentColor или CSS-переменные
- Hover — это смена color или fill в один CSS-класс
Разница в весе — порядок. Разница в гибкости — несравнимая. И при этом SVG-иконка масштабируется до любого размера без блюра.
Вопросы на ревью набора иконок:
- Все иконки в одном формате (SVG)?
- Цвет управляется через CSS, а не зашит в файл?
- Размеры обводок и пропорции согласованы между иконками?
- Нет лишних , метаданных Figma, комментариев в SVG-коде?
- Иконки оптимизированы через SVGO или аналог?
Последний пункт — отдельная боль. Сырой SVG из Figma может весить в 3-5 раз больше, чем тот же SVG после прогона через оптимизатор. Это бесплатное ускорение, которое почему-то делают не все.
Сценарий: фото и hero-баннеры
Тут другая история. Иконку можно случайно сохранить в SVG и не сильно проиграть. А вот hero-баннер, экспортированный в PNG, — это почти всегда несколько лишних мегабайт на первом экране.
Плохо:
- Hero — PNG 2880×1620, потому что «нужно для ретины»
- Один файл на все размеры экрана
- Никаких srcset и sizes, браузер тянет полную версию даже на телефон
Хорошо:
- WebP (или AVIF + WebP как fallback) в нескольких размерах
- с source под разные ширины
- loading="lazy" для всего, что ниже первого экрана
- width и height проставлены, чтобы не было сдвигов лэйаута
Дизайнер не обязан сам писать . Но обязан отдать разработчику исходник в правильном формате и в нескольких размерах — а не один гигантский PNG «вы там сами разберитесь».
Мини-чеклист для hero-картинки
- Исходник — WebP или AVIF, не PNG
- Есть версии под mobile, tablet, desktop
- Размер каждой версии — порядка десятков, а не сотен КБ
- Если на картинке текст — он не зашит в растр, а лежит отдельным слоем HTML
- Картинка не блокирует LCP — то есть отдаётся приоритетно, а не лениво
Рабочий процесс: договорённости важнее настроек
Главная ошибка — думать, что вопрос экспорта решается «правильными настройками в Figma». Не решается. Решается договорённостью на уровне команды.
Что закрепить в гайдлайнах продукта
- Какой формат для какого типа ассета (одной строкой, без «зависит от случая»)
- Какие максимальные размеры файлов считаются приемлемыми
- Где лежат иконки и как они подключаются (спрайт, инлайн, библиотека компонентов)
- Кто отвечает за оптимизацию: дизайнер на этапе экспорта или CI на этапе сборки
Если этого нет — каждый дизайнер и каждый разработчик решают по-своему, и в проекте через полгода соседствуют PNG, JPG, SVG и WebP в случайном порядке.
Передача в разработку
На ревью макета полезно явно подписывать ассеты: «лого — SVG», «фото — WebP, 3 размера», «иконки — из библиотеки, не экспортировать». Это убирает половину вопросов в чате и половину переделок.
Если работаете через Figma-плагины или MCP-интеграции, которые выгружают ассеты автоматически, — всё равно проверяйте, что именно ушло. Автоматика спокойно отдаёт PNG там, где должен быть SVG, если её об этом не попросили. Инструмент не знает, что у вас «логотип», а что — «фотография блюда».
Диагностика: как понять, что формат выбран неправильно
Не нужно ждать жалоб от пользователей. Большая часть проблем видна за пять минут.
Быстрая проверка в браузере
- Открыть DevTools → Network → отфильтровать по Img
- Отсортировать по размеру
- Посмотреть на топ-10 самых тяжёлых картинок
Дальше задаём по каждой три вопроса:
- Это фото или вектор? Если вектор и весит больше 100 КБ — что-то не так.
- Какой формат? Если PNG больше 200 КБ и это не прозрачность поверх сложного фона — кандидат на WebP.
- Где это используется? Если картинка показывается размером 400 px, а отдаётся в 2400 px — лишний вес без причины.
Сигналы в Lighthouse
В отчёте обращайте внимание на три пункта:
- «Serve images in next-gen formats» — намёк, что где-то лежит PNG/JPG вместо WebP/AVIF
- «Properly size images» — отдаются картинки больше, чем нужно
- «Efficiently encode images» — даже в правильном формате сжатие можно усилить
Эти пункты не косметика. Каждый из них — это конкретные мегабайты, которые пользователь не должен был качать.
Типичные ошибки на ревью макета
- Логотип в шапке экспортирован как PNG, потому что «так получилось»
- Иллюстрация-баннер — SVG с трассированной фотографией внутри
- Иконки набора — половина SVG, половина PNG, цвета зашиты в файлы
- Скриншот интерфейса в статье — PNG на 2 МБ, хотя WebP дал бы 200 КБ без видимой разницы
- Аватарки пользователей — PNG с прозрачностью, хотя там круглая маска и фон всегда заливной
Каждая из этих ошибок — мелочь. Десять таких мелочей на странице — и она грузится вдвое дольше, чем могла бы.
Вопросы, которые стоит задать себе перед отдачей макета
- Каждый ассет в макете я могу объяснить: почему именно этот формат?
- Есть ли в наборе PNG, который должен был быть SVG?
- Есть ли SVG, который на самом деле растр в обёртке?
- Я экспортировал в нужных размерах или скинул «как было»?
- Прогнал SVG через оптимизатор, а растры — через сжатие?
Если на все пять — да, передача будет короткой и без переделок. Если хоть на один — нет, лучше потратить десять минут сейчас, чем разбираться с Lighthouse-отчётом через неделю.
Продвинутые сценарии: где формат особенно легко промахнуться
Базовые правила «фото — WebP, иконки — SVG» закрывают 80% случаев. Остальные 20% — это именно те ситуации, где сайт начинает тормозить непонятно почему или ассеты ломаются в неожиданных местах.
Тёмная тема и SVG
Иконки с зашитым цветом fill="#1a1a1a" отлично смотрятся в светлой теме и становятся почти невидимыми в тёмной. Правильное решение — fill="currentColor" и управление цветом через CSS. Если иконки приходят от дизайнера с жёстко прописанными цветами, тёмная тема превращается в ручную правку каждого файла.
На ревью полезно проверить иконку в обеих темах прямо в браузере, а не только на макете.
Анимированные ассеты
Здесь самый частый промах — экспорт анимации как GIF. GIF весит в разы больше, чем нужно, ограничен по цвету и часто выглядит грязно. Альтернативы по убыванию веса:
- Lottie (JSON) — для векторной анимации из After Effects/Figma
- SVG-анимация — для простых движений интерфейса
- WebM/MP4 с autoplay muted loop — для всего, что снято камерой или содержит много пикселей
- APNG/анимированный WebP — узкие ниши, если нужна прозрачность
GIF на современном сайте — почти всегда ошибка передачи, а не осознанный выбор.
Ретина и плотности пикселей
Картинка, которая на макете 400×400, на ретине должна быть готова к показу как 800×800. Но это не значит, что нужно отдать всем устройствам 2x — телефон с обычным экраном будет качать лишнее. Связка srcset и sizes решает это, но только если дизайнер отдал не одну версию, а набор.
Тут полезный мини-формат передачи: имя файла с суффиксами @1x, @2x, @3x или с шириной в пикселях. Разработчику не нужно гадать, что именно перед ним.
Иконки в письмах и PDF
Если ассет уйдёт за пределы сайта — в email-рассылку, экспорт в PDF, шаблон для презентации, — SVG может не поддерживаться. Для писем безопаснее PNG. Это исключение, но про него регулярно забывают и потом удивляются, почему в почте у половины подписчиков пустые квадраты.
AI-инструменты и автогенерация ассетов
Плагины, MCP-интеграции и генеративные модели всё чаще участвуют в подготовке графики. Это меняет рабочий процесс, но не отменяет вопрос формата — а часто наоборот, обостряет его.
Что делает AI хорошо
- Превращает скетч в чистый вектор
- Генерирует варианты иллюстрации в заданном стиле
- Массово ресайзит и переэкспортирует ассеты
- Подсказывает альтернативные форматы по содержимому файла
Где AI стабильно ошибается
- Отдаёт растр там, где нужен вектор, потому что «картинка готова»
- Делает SVG с тысячами узлов из простой формы
- Игнорирует прозрачность или, наоборот, добавляет ненужный альфа-канал
- Сохраняет в PNG то, что должно было стать WebP, потому что PNG — формат по умолчанию
Главный риск автоматизации в том, что плохие ассеты появляются быстрее, чем команда успевает их ревьюить. Один человек руками не залил бы в репозиторий 40 PNG по 1.5 МБ. Скрипт залил.
Как встроить проверку
- В CI — шаг с svgo для SVG и sharp/squoosh для растров, с порогом по размеру
- В код-ревью — явный пункт «новые ассеты соответствуют гайду форматов»
- В Figma — библиотека компонентов, из которой берут иконки, вместо повторного экспорта одного и того же
Автоматика хороша как фильтр последнего рубежа, а не как замена решению дизайнера.
Как объяснять выбор формата команде
Разработчики и продакты редко спорят с дизайнером по форматам — но они и не понимают, почему «нельзя просто PNG». Если не объяснить, через полгода в проекте опять окажутся скриншоты по 3 МБ.
Аргументы, которые работают
- «WebP экономит N килобайт на этой картинке — на мобильной сети это секунды загрузки»
- «SVG масштабируется без потерь — на ретине лого не размылится»
- «Иконки из спрайта кешируются один раз — следующая страница откроется быстрее»
- «Если отдать одну тяжёлую картинку — пострадает LCP, а это метрика Core Web Vitals»
Связывайте формат не со вкусом, а с метрикой. «Так красивее» — не аргумент. «Это уберёт жёлтое предупреждение в Lighthouse и ускорит первую отрисовку» — аргумент.
Анти-паттерны коммуникации
- Говорить «SVG лучше», не уточняя, для чего именно
- Требовать переделку без объяснения, что сломается, если оставить как есть
- Молча перезаливать ассеты после разработчика — он не поймёт, в чём была ошибка, и повторит её
Короткий комментарий «логотип лучше SVG, потому что он показывается в шапке на всех экранах и должен быть чётким на ретине» экономит час споров в следующий раз.
Короткий итог сегмента
Сложные сценарии — тёмная тема, анимация, ретина, AI-генерация — это не исключения из правил, а места, где правила работают строже всего. Команда, которая умеет объяснять выбор формата через метрики и пользовательский сценарий, перестаёт спорить о PNG и SVG и начинает обсуждать продукт.
Чеклист перед коммитом ассетов
Один и тот же список, который стоит держать перед глазами при экспорте и при ревью пул-реквеста с новой графикой.
Перед экспортом из Figma
- Понял, где этот ассет будет жить: hero, иконка в кнопке, фон секции, иллюстрация в карточке
- Определился с типом: вектор, фото, скриншот, иллюстрация с градиентами
- Выбрал формат осознанно, а не «как обычно»: SVG для вектора, WebP для фото и сложного растра, PNG только если нужна прозрачность и WebP по какой-то причине не подходит
- Для растра подготовил минимум две плотности — 1x и 2x — и понял, какие нужны вообще
- Очистил SVG от лишних слоёв, эффектов и невидимых объектов
- Проверил, что прозрачность нужна — или, наоборот, что её точно нет
- Имя файла говорит о назначении, а не о номере фрейма в макете
Перед мерджем PR с ассетами
- Размер файла укладывается в бюджет страницы, а не «ну, это же всего 400 КБ»
- есть width, height и altУ
- Для растра отдан srcset и sizes, если картинка показывается на разных ширинах
- Для фона учтён dark mode, если он есть в продукте
- LCP-картинка приоритизирована, остальное — loading="lazy"
- SVG прогнан через svgo или аналог, растр пережат
- Иконки взяты из общей системы, а не уникальный экспорт «только для этой страницы»
Анти-паттерны, которые повторяются из проекта в проект
«Сделаю PNG, чтобы наверняка»
Самый частый. PNG воспринимается как безопасный формат — поддерживается везде, ничего не сломает. Цена — мегабайты там, где хватило бы сотен килобайт. Безопасно для дизайнера, дорого для пользователя.
Один SVG-логотип на всё
Сложный лого с градиентами и тенями выгружают в SVG, потому что «лого должен быть вектором». В итоге файл весит как PNG, рендерится медленнее, а в Safari ещё и выглядит иначе. Иногда честный PNG@2x — правильный выбор.
Иконки как картинки
Каждая иконка лежит отдельным файлом, подключается через
, не управляется через currentColor. При смене темы иконки не меняют цвет, и приходится держать два комплекта. Решение — спрайт или React/Vue-компоненты со встроенным SVG.
Скриншоты в JPEG
Скриншот интерфейса с текстом в JPEG — это всегда мыло на буквах. Для скриншотов с UI нужен PNG или WebP без потерь, не классический JPEG.
«Залью оригинал, фронт пережмёт»
Дизайнер кидает 8 МБ из камеры, надеясь, что CDN или сборка всё исправят. Иногда исправляют, иногда нет. И почти никогда не исправляют так же хорошо, как осознанный экспорт.
Вопросы для ревью дизайна и кода
Их полезно задавать вслух — себе или коллеге — пока не станут рефлексом.
- Этот ассет точно должен быть растром? Что мешает сделать его вектором?
- Эта картинка — LCP-элемент страницы? Как мы это учли?
- Сколько весит ассет и в какой бюджет страницы он попадает?
- Что произойдёт с ним на ретине? На медленной сети? В тёмной теме?
- Откуда берётся эта иконка — из библиотеки или это разовый экспорт?
- Если завтра поменяется акцентный цвет, сколько ассетов придётся переделывать руками?
- Этот файл уже есть в проекте под другим именем?
Если на половину вопросов ответ «не знаю» — ассет ещё не готов к мерджу.
Практический итог
Выбор между SVG, PNG и WebP — это не вопрос вкуса и не догма из чек-листа. Это короткая цепочка решений: что за контент, где он показывается, кому и через какую сеть, как он будет жить через год.
Вектор — для всего, что можно описать формами и должно масштабироваться. WebP — для фото и сложного растра, где важен вес. PNG — для прозрачности и случаев, когда WebP не подходит по среде.
Команда, в которой эти решения принимаются осознанно и проговариваются на ревью, перестаёт ловить «непонятные» проблемы с производительностью и визуальным качеством. Формат ассета — это не оформление, это часть продукта.
Источник и полная версия: VibeCode Wiki