Вес файла инфографики: как снизить без потери качества и не потерять в скорости загрузки

Тяжёлый файл инфографики — это не абстрактная проблема «для айтишников». Он либо мешает загрузить слайд в карточку сразу, либо (если загрузился) тормозит показ там, где скорость зависит от вас. Здесь стоит сразу развести два разных «весовых» вопроса: примет ли площадка файл такого размера при загрузке — и как быстро он будет показываться дальше. Второе — не про то, сколько времени вы тратите на производство самой инфографики (это отдельная тема), а про то, сколько миллисекунд ждёт покупатель, когда изображение уже открывается у него на экране. В этой статье — про формат, сжатие и вес файла: как их готовить, чтобы карточка не спотыкалась ни на загрузке, ни на показе.

Почему вес файла инфографики — не мелочь

У веса файла инфографики две разные стороны, и их легко перепутать.

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

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

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

PNG, JPEG, WebP — что за форматы и зачем разбираться

Прежде чем снижать вес, полезно понимать, что вообще происходит внутри файла при сохранении.

PNG — растровый формат со сжатием без потерь (lossless): при экспорте не выбрасывается ни один пиксель информации, поэтому чёткие границы, ровные заливки и текст на PNG остаются идеально резкими. Обратная сторона — на сложной, «шумной» картинке (много деталей, плавных градиентов, текстур) PNG может весить заметно больше, чем тот же кадр в другом формате: lossless-сжатие честно хранит всю картину, а не «упрощает» её.

JPEG — формат со сжатием с потерями (lossy), изначально спроектированный под фотографии: плавные переходы тона, естественный шум изображения. За счёт отбрасывания части информации JPEG даёт компактный вес на фото, но плохо ведёт себя на резких контурах — подробнее это разобрано в следующем разделе.

WebP — более новый формат, который умеет работать в обоих режимах: и lossless (как PNG), и lossy (как JPEG) — в зависимости от того, как файл экспортирован. Именно поэтому WebP для карточки товара часто выбирают как компромисс: один формат, который в теории покрывает и текстовые/плашечные элементы, и фотовставки. На практике конвертировать PNG в WebP для инфографики с текстом имеет смысл в lossless-режиме — иначе получите тот же риск смазывания текста, что и в JPEG.

Что касается самого выигрыша WebP против JPEG по весу — по вторичным источникам, ссылающимся на тесты Google, экономия составляет ориентировочно 25–34% при сравнимом визуальном качестве. Это именно ориентир, а не фиксированный процент: на плоской графике и карточках с текстом (как раз случай инфографики) экономия обычно выше, чем на сложных фотосценах, потому что там меньше «шумной» информации, которую вообще нужно кодировать.

Почему JPEG «мажет» текст и мелкие детали инфографики

Если инфографика на карточке товара выглядит «мыльной» именно на тексте и тонких линиях таблиц, а не на фото — вероятная причина в механике самого JPEG.

JPEG сжимает изображение через дискретное косинусное преобразование (DCT): картинка раскладывается на частотные составляющие, а часть высокочастотной информации при сжатии отбрасывается или огрубляется — это и даёт экономию веса. На плавных фотографических переходах человеческий глаз почти не замечает потерю этих высоких частот. А вот на резких границах — тексте на плашке, тонких линиях таблицы, контрастных иконках на однотонном фоне — отброшенные частоты дают побочный эффект: «звон» (ringing), паразитные волнообразные ореолы вокруг контура. Именно из-за них мелкий текст на JPEG-инфографике часто выглядит смазанным, будто «дрожащим», особенно после повторного сохранения или агрессивного уровня компрессии. По сути это аналог явления Гиббса в обработке сигналов, только применительно к изображению (вторичный источник, техническое объяснение механизма компрессии).

PNG как lossless-формат эту информацию не режет — контур остаётся точным вне зависимости от того, насколько резкая граница.

Отсюда практическое правило: инфографика — это в первую очередь плоская графика и текст, а не фотография, поэтому кандидат на PNG или WebP в lossless-режиме. Фотография внутри слайда (например, кадр товара на фоне инфографики) — кандидат на JPEG или WebP в lossy-режиме, там ringing не так критичен.

Lossless и lossy: что реально уменьшает вес без потери качества

Термины «lossless» и «lossy» — не просто маркетинговые слова у форматов, а два принципиально разных способа снижать вес файла.

Lossless-сжатие (PNG, WebP в lossless-режиме, а также отдельные оптимизаторы вроде повторного квантования цветовой палитры) уменьшает вес без визуальной потери — это и есть буквально «сжатие без потери качества». Оно работает за счёт более эффективной упаковки данных, а не за счёт выбрасывания части картинки. Именно это и имеют в виду, когда говорят «уменьшить вес фото без потери качества»: вес падает, а картинка попиксельно остаётся прежней.

Lossy-сжатие (JPEG, WebP в lossy-режиме) снижает вес гораздо агрессивнее, но за счёт реального выбрасывания части информации — квантования цвета и частотных составляющих. На фотографии эта потеря чаще всего незаметна глазу. На инфографике с текстом и резкими контурами она заметна значительно быстрее — иногда уже на первом уровне сжатия, как показано выше на примере ringing.

Практический вывод для подготовки файла инфографики: не снижать «качество» вслепую одним ползунком, а сначала пройти lossless-путь (правильный формат, оптимизация палитры) и только затем, если вес всё ещё велик, добавлять лёгкую lossy-компрессию с обязательной визуальной проверкой результата — как именно проверять, разобрано в разделе про контроль перед загрузкой.

Принимают ли маркетплейсы WebP: что говорят требования площадок

Отдельный частый вопрос — примет ли конкретная площадка файл в WebP, или безопаснее оставаться на JPG/PNG. Однозначного «одна площадка — одно правило навсегда» здесь нет: требования у площадок разные и обновляются, поэтому ниже — то, что зафиксировано в доступных источниках на дату публикации, а не универсальная гарантия.

По официальной странице поддержки Wildberries для сервиса «Виртуальная примерка» в списке поддерживаемых форматов для загружаемых фото прямо указаны JPG, PNG и WEBP (при рекомендуемом разрешении от 700×933 px) — это смежная функция, не основная фотогалерея карточки, но тот же набор форматов (JPG/PNG/WebP) для основных фото карточки повторяют и независимые вторичные источники. Точный процент сжатия или минимальный порог качества, который выставляет площадка, официальным первоисточником с дословной формулировкой не подтверждён — поэтому в этой статье фиксируется только общий факт: площадка выставляет минимальный порог качества сжатия, без конкретной цифры. Больше о требованиях WB к фото — в отдельном материале про требования Wildberries к фотографиям.

Яндекс Маркет по официальной документации поддержки принимает форматы .jpg, .jpeg, .png, .heic, .webp, вес файла — не более 10 МБ, минимальный размер — от 300×300 px. Там же оговорено, что в поисковой выдаче и на витрине покупатель видит уже адаптированное площадкой изображение, а не исходный файл, — об этом подробно в следующем разделе.

По данным базы знаний Мегамаркета (вторичный источник) поддерживаются форматы JPG/JPEG/WEBP/PNG при разрешении от 500×500 до 5000×5000 px.

По вторичным источникам, Ozon поддерживает JPEG/JPG/PNG/HEIC/WEBP с ограничением веса файла до 10 МБ; официальную базу знаний Ozon по актуальным параметрам стоит сверять отдельно.

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

Вес исходника — не вся история: что дальше делает площадка

Даже идеально подготовленный лёгкий файл — это только половина истории про скорость. После загрузки площадка не показывает покупателю исходный файл «как есть»: витрина и поисковая выдача используют адаптированные версии изображения. Яндекс Маркет прямо формулирует это в своей документации: «В поисковой выдаче и на витрине покупатели видят адаптированные изображения в формате 3 × 4» — то есть то, что видит покупатель, это уже не исходный файл, а его обработанная площадкой версия.

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

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

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

Как подготовить файл инфографики на практике

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

1. Собирайте макет сразу в разрешении под площадку — без увеличения после экспорта. Апскейл уже сжатого или маленького файла не добавляет реальных деталей — он только увеличивает вес и съедает видимую резкость.
2. Слои с текстом, плашками и резкими линиями экспортируйте в PNG или WebP в lossless-режиме — так контур и буквы останутся чёткими.
3. Фотовставки внутри слайда (если они есть) экспортируйте в JPEG или WebP в lossy-режиме с умеренной степенью сжатия — на фотографии это не заметно глазу, а вес ощутимо ниже, чем в PNG.
4. Прогоните готовый экспортированный файл через компрессор и сверьте итоговый вес с ориентировочным лимитом площадки — порядок величины обычно измеряется единицами мегабайт, но точный лимит по конкретной площадке проверяйте в её актуальных требованиях на дату загрузки (см. сравнение выше).
5. Визуально сверьте результат при масштабе 100% — не «поплыл» ли текст, не появились ли ореолы вокруг букв и линий после сжатия. Автоматическая проверка веса не заменяет визуальную.

Как проверить результат перед загрузкой

Финальный шаг — контроль перед публикацией, а не после.

Инструменты сжатия изображений, которых достаточно для контроля результата, — общедоступные онлайн-компрессоры с превью до/после: они показывают и итоговый вес, и то, что стало с картинкой. Для собственного сайта (не для карточки на маркетплейсе — это разные среды) полезен Google PageSpeed Insights или Lighthouse: в официальной документации Google по оптимизации изображений использование «next-gen форматов» (WebP и аналогичных) прямо названо одной из типовых точек роста для сайтов с невысоким performance-баллом.

Три вещи, которые стоит проверить перед загрузкой готового файла:

• итоговый вес файла — против ориентировочного лимита конкретной площадки;
• визуальную резкость текста и мелких деталей при масштабе 100%;
• отсутствие ореолов (ringing) вокруг контуров после сжатия — особенно если применялось lossy-сжатие.

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

Типичные ошибки при сжатии инфографики

В отличие от остального текста, здесь речь про то, чего делать точно не стоит:

• Апскейл после экспорта. Растягивание уже сохранённого файла до нужного разрешения не возвращает потерянные детали — оно только увеличивает вес и делает текст более размытым, а не более чётким.
• Агрессивный lossy на тексте. Сильное lossy-сжатие (JPEG или WebP lossy на низком качестве) на слайде с текстом почти всегда даёт заметный ringing вокруг букв — экономия в весе не стоит потери читаемости.
• Пересохранение JPEG поверх JPEG. Каждое повторное сохранение в lossy-формате добавляет новый цикл потерь поверх предыдущих — артефакты накапливаются, даже если исходная степень сжатия была умеренной.
• «Сжали и не посмотрели на 100%». Автоматический компрессор снижает вес, но не гарантирует, что текст остался читаемым — визуальная проверка при полном масштабе обязательна перед загрузкой, а не после жалоб на карточку.

Коротко

Вес файла инфографики влияет на карточку в двух разных точках: пройдёт ли файл загрузку по лимитам площадки — и как быстро он будет показываться там, где скорость зависит от вас. PNG держит текст и резкие контуры чётко за счёт lossless-сжатия, JPEG компактен на фото, но «мажет» текст через ringing, WebP умеет оба режима сразу. Практический путь — собирать макет в целевом разрешении, разносить текстовые и фотографические элементы по подходящим форматам, сжимать без потери читаемости и обязательно сверять результат визуально при 100% масштабе перед загрузкой — а требования конкретной площадки по весу и формату проверять в её актуальной документации на момент публикации.