WebP и AVIF для лендинга: тест 12 JPEG, размеры и цена обработки

WebP и AVIF это форматы изображений, которые помогают уменьшить вес картинок на лендинге. Для байера смысл в том, чтобы посетитель увидел товар и форму после оплаченного клика. Но лёгкий файл ещё не означает быстрый первый экран. Мы скачали 12 JPEG с действующего сайта услуг, перекодировали их и сравнили вес, время обработки и сходство с оригиналом. Ниже результаты, тарифы сервисов и порядок замены картинок без поломки ленда.

Короткий результат: AVIF с шириной до 780 пикселей сократил общий вес на 73,8%. При исходном разрешении WebP дал 38,4%, AVIF 51,8%; AVIF легче WebP на всех 12 файлах. WebP с шириной до 780 пикселей дал 62,2%. Это замер файлов, а не скорости сайта или конверсии. Уменьшение ширины WebP дало больше экономии, чем переход с полного WebP на полный AVIF.

Материал подготовлен 26 октября 2026 года. В этот день проверены все ссылки на документацию и тарифы ниже. Цены указаны в долларах, без пересчёта в рубли. Расчёты трафика используют десятичные мегабайты и гигабайты; в таблицах файлов один КиБ равен 1024 байтам. Сайт-источник при проверке не меняли, рекламу и заявки не запускали.

Что именно ускоряет формат картинки

После клика браузер получает HTML, находит адрес картинки, скачивает файл и декодирует его. В этом пути есть ожидание сервера, поиск ресурса и отрисовка. Смена JPEG на WebP уменьшает прежде всего объём передачи. Если картинку подставляет скрипт через несколько секунд после загрузки, выигрыш от сжатия легко потеряется в этой задержке.

В документации по оптимизации LCP этот путь разобран на четыре части: ответ сервера, задержка начала загрузки ресурса, сама загрузка и задержка отображения. LCP измеряет момент появления самого крупного подходящего элемента в первом экране. Им может оказаться текст, а не фотография. Ориентир web.dev для хорошего LCP составляет 2,5 секунды или меньше на 75-м процентиле загрузок, отдельно для мобильных и настольных устройств. Это рекомендация по метрике, а не универсальный норматив модерации рекламы.

Отсюда порядок работы. Сначала найдите элемент LCP и посмотрите, когда началась его загрузка. Затем уменьшайте файл. Если фотография уже весит 25 КиБ, а сервер отвечает две секунды, новый кодек не исправит сервер. Если на телефон скачивается фон шириной 2500 пикселей, начните с мобильной версии. Основы структуры посадочной страницы разобраны в материале про лендинг; здесь речь именно о картинках и их доставке.

Рекомендация Image performance связывает экономию с двумя действиями: передавать меньше байтов и подбирать изображение под устройство. Сравнивать нужно эти действия по отдельности. Иначе после уменьшения ширины легко приписать кодеку весь результат. Аналогично нельзя назвать повторное открытие из кеша доказательством ускорения первой загрузки.

WebP, AVIF, JPEG и PNG под разные задачи лендинга

У WebP есть сжатие с потерями, режим без потерь и прозрачность. Его официальное описание называет экономию относительно JPEG при сопоставимом SSIM, то есть индексе сходства. Эти результаты Google нельзя автоматически переносить на конкретный ленд. Старый JPEG уже мог пройти сильное сжатие, а картинка с мелкими буквами потребует другого качества, чем фон.

AVIF хранит изображения на базе AV1. Устройство контейнера описано в спецификации AV1 Image File Format, а утилиты для кодирования и декодирования находятся в проекте libavif. Для команды практический вопрос проще: насколько меньше конкретный файл и устраивает ли его вид. В нашем прогоне AVIF кодировался дольше WebP. Его обычно выполняют до загрузки на сайт, поэтому посетитель не должен ждать перекодирования при каждом клике.

Это схема выбора для теста, составленная по справочнику форматов MDN и рекомендациям web.dev по выбору изображения. Она не означает, что AVIF всегда выигрывает у WebP. Особенно осторожно стоит обращаться с ценами и дисклеймерами, вписанными в растр. Цветные ореолы вокруг букв могут сделать более лёгкую картинку непригодной. Если надпись можно оставить обычным HTML-текстом, она сохранит резкость и возможность выделения.

Для объявления и для лендинга правила разные. Поддержка AVIF браузером ничего не говорит о загрузке этого файла в рекламный кабинет. Форматы креативов проверяйте отдельно по требованиям площадок к рекламному креативу. В карточку объявления может понадобиться JPEG, а на посадочной странице тот же сюжет можно отдать как WebP.

Прозрачность в нашем сравнении ниже не тестировалась. В выборку вошли только JPEG; все PNG и автоматически созданные миниатюры исключены. Превратить прозрачную картинку в RGB и записать маленький JPEG было бы некорректным сравнением: фон исчезнет или изменится. Такой результат нельзя считать удачным сжатием, даже если вес снизится в несколько раз.

Наш замер: реальные JPEG и три варианта перекодирования

26 октября 2026 года мы собрали 12 разных JPEG из публичной разметки сайта ремонта окон. Обошли главную и страницы услуг, включая стеклопакеты и москитные сетки. В набор попали фоны, фотографии и иллюстрации. Это небольшая удобная выборка одного сайта, а не случайная выборка всех рекламных лендингов.

Скрипт брал первые подходящие адреса по порядку обхода семи страниц. Одинаковые URL исключались; имена миниатюр вида «-300×200» отбрасывались. Отдельно пропускали файлы с cropped- в имени и три портретных файла сотрудников den01, vikt01 и lesha01: задача касалась иллюстраций услуг и фонов. Минимальная сторона должна была составлять 150 пикселей. Такой отбор нужен, чтобы не посчитать иконки и несколько размеров одной фотографии как разные сюжеты. Исходные байты, адреса и SHA-256 сохранены. Сумма исходных файлов составила 796 625 байт.

Каждый JPEG декодировали в RGB и отдельно записали в JPEG quality 80, WebP quality 80 с методом 4 и AVIF quality 60 со скоростью 6. Разрешение в основной серии не меняли. JPEG сохранялся с оптимизацией и прогрессивной развёрткой. AVIF работал в одном потоке. Использовали Pillow 10.2.0, libwebp 1.3.2 и pillow-avif-plugin 1.6.0 с libavif 1.4.2 на Linux. Файлы обрабатывались последовательно. Выбор кодека оставили в режиме auto; в сборке есть aom 3.14.1, rav1e 0.8.1 и svt 4.1.0. Эти версии фиксируют условия замера: при обновлении библиотек результат может измениться. Время измеряли вокруг записи в память, без скачивания и расчёта SSIM.

Число quality нельзя сравнивать между кодеками как общую шкалу качества. Наши 80 для WebP и 60 для AVIF это выбранные настройки, а не эквивалентные уровни. О параметрах WebP можно прочитать в руководстве cwebp, об API сохранения изображений в справке Pillow. Параметры расширения AVIF сверяются с установленным плагином: новые версии Pillow уже имеют собственную поддержку формата.

В колонке JPEG показана повторная запись, а не исходник. После пересохранения JPEG quality 80 два файла из 12, номера 01 и 03, стали больше исходника. Сравнение современных форматов с уже сжатым JPEG оценивает следующий шаг обработки. Оно не отвечает на вопрос, насколько хорошо кодировался бы первоначальный RAW или PNG из редактора.

Кроме веса, мы посчитали SSIM по декодированным RGB-массивам с диапазоном значений 255, используя skimage.metrics.structural_similarity. Медианы составили 0,9987 для JPEG, 0,9813 для WebP и 0,9821 для AVIF. Чем ближе результат к единице, тем больше структурное сходство в этой метрике. SSIM не измеряет убедительность фотографии и не подтверждает читаемость всех надписей. Для этого нужен просмотр.

Одинаковые quality не заменяют визуальную проверку. Здесь нет вывода «AVIF лучше при равном качестве»: мы не выравнивали все пары до одного SSIM. При этих настройках AVIF меньше WebP на всех 12 файлах: суммарно на 21,8%. SSIM у AVIF не ниже на 10 файлах из 12. У файлов 05 и 10 он ниже на 0,00082 и 0,00007 соответственно. По размеру и этой метрике AVIF в нашем наборе выглядит предпочтительнее.

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

Ниже увеличенные фрагменты фона 02: исходный JPEG, WebP и AVIF. В каждой панели одна область размером 240 на 65 пикселей. При отображении всей иллюстрации шириной 760 пикселей фрагмент увеличен примерно втрое; на телефоне масштаб меньше. Числа SSIM относятся к полным файлам. На этом светлом фоне различия тонкие, поэтому одного просмотра уменьшенной картинки недостаточно для решения о качестве.

Почему ширина под телефон дала больше экономии

Отдельно мы создали WebP quality 80 с максимальной шириной 780 пикселей. Узкие оригиналы не увеличивали, пропорции сохраняли. Число 780 выбрано как ориентир для изображения шириной 390 CSS-пикселей при плотности два пикселя на один CSS-пиксель. Это условие нашей дополнительной серии. Оно не подходит автоматически каждому телефону, блоку и варианту вёрстки.

Сумма этой серии составила 300 870 байт. От исходного набора это на 62,2% меньше. По сравнению с WebP полного разрешения экономия составила 38,7%. При этом кодек и quality остались прежними: в больших фонах стало меньше пикселей. Но на широком настольном экране та же версия может выглядеть мягче, поэтому заменять ею все размеры нельзя.

Чтобы отделить размер от формата, мы повторили все три режима с шириной до 780 пикселей. Даже JPEG quality 80 после уменьшения занял 477 555 байт: на 38,0% меньше JPEG quality 80 полного размера. AVIF шириной до 780 занял 208 876 байт, на 73,8% меньше исходников. Для этого набора самый лёгкий вариант получился при сочетании уменьшения и AVIF.

У фонового блока есть дополнительное условие. Если узкий высокий экран использует background-size: cover, широкий фон 1920 на 600 после уменьшения может снова растянуться. Для такого блока подготовьте мобильный кроп под его пропорции, а затем выбирайте разрешение. Наша серия меняла только ширину и сохраняла исходные пропорции.

Браузеру лучше предложить несколько вариантов через srcset и сообщить ширину изображения в раскладке через sizes. В руководстве MDN по адаптивным изображениям отдельно разобраны размер области и плотность экрана. В описании img указано, что значения ширины в srcset должны соответствовать реальным файлам. Если написать «780w» на файле шириной 1920 пикселей, браузер получит ложную подсказку.

Вариантов не должно быть бесконечно много. Для одного блока можно начать с двух или трёх размеров и проверить реальные запросы. Набор 390, 780 и 1200 пикселей здесь лишь пример, а не обязательная сетка. Сопоставьте его с шириной контейнера и устройствами вашей аудитории. Для прелендинга с длинным текстом часть иллюстраций может оставаться вне первого экрана и загружаться позже.

Сохранить пропорции помогает явное указание width и height. Браузер резервирует место до получения изображения, что уменьшает скачки раскладки. Это поведение описано в MDN для img. Особенно неприятен скачок возле кнопки заявки: человек целится в кнопку, а после прихода картинки она уезжает вниз. Сжатие файла само по себе пропорции блоку не задаёт.

При доставке через CDN фиксируйте небольшой набор размеров. Для файлов в собственном хранилище Cloudflare Images есть variants, заранее заданные варианты обработки. Для внешних оригиналов размеры и формат задают параметрами трансформации в URL. Случайный новый размер в каждом URL усложнит кеширование и учёт операций. Для повторяющихся блоков ленда удобнее небольшой одинаковый набор.

Сколько это даёт в байтах и расходах команды

Экономия полного WebP-набора составила 305 651 байт: из 796 625 вычитаем 490 974. Делим разность на исходный вес и умножаем на сто, получаем 38,4%. Аналогично рассчитаны остальные проценты. При 10 000 полных скачиваний такого набора разность составила бы 3,06 ГБ для WebP и 4,13 ГБ для AVIF. Количество загрузок в этом расчёте задано условно.

Слово «полных» здесь существенно. Человек может закрыть страницу до галереи; браузер может взять файл из кеша; картинки могут стоять на разных страницах. Наши 12 файлов собраны с нескольких адресов, поэтому нельзя приписать весь набор одному визиту. Для своего ленда подставляйте в формулу только реально запрошенные файлы и число загрузок без кеша.

Время в последней колонке рассчитано делением количества битов на заданную скорость 10 Мбит/с. Там нет задержки сети, TLS, конкурирующих запросов, декодирования и скриптов. Колонка оценивает только время передачи заданного числа байтов. Реальное время первого экрана измеряется в браузере.

Для байера главная статья расходов обычно связана с платными кликами, но приписывать им экономию по размеру картинки нельзя. В нашем тесте не было рекламных групп и данных о лидах. Чтобы связать изменение с результатом, оставьте одинаковыми оффер, аудиторию и креатив, а варианты ленда разделите корректным экспериментом. Измеряйте загрузки, заявки и подтверждённые лиды. Расчёт этих показателей есть в статье про ROI, CR и EPC.

В Meta Ads сравните клики по ссылке с просмотрами целевой страницы, Landing Page Views. В справке Meta, проверенной 26.10.2026, эта метрика описывает загрузку страницы после клика. Разрыв между этими столбцами помогает заметить уходы до загрузки. Считают его как разность кликов и просмотров, делённую на клики; для процента умножают на сто. Сравнивайте одинаковый период, креатив, аудиторию и способ учёта у двух вариантов ленда.

Это диагностическая метрика: разрыв также связан с поведением посетителей и учётом событий. Meta сообщает о регистрации через встроенный браузер или пиксель и о возможном моделировании при неполных данных. Поэтому сокращение разрыва проверяйте вместе со временем первого экрана и заявками. Мы не замеряли этот показатель на рекламе и не приписываем весь разрыв весу картинок.

Даже хороший результат по заявкам может не окупить внедрение, если объём маленький. В себестоимость войдут работа разработчика, проверка вариантов, хранение оригиналов и платный обработчик, если он нужен. Наша суммарная запись AVIF заняла 8,67 секунды, WebP 1,04 секунды: AVIF примерно в 8,4 раза дольше. Это один последовательный проход; для оценки производительности большой очереди его недостаточно. Для ночной подготовки десятка картинок обе длительности невелики; перекодировать большую библиотеку лучше отдельно от запросов посетителей.

Цены: локальная обработка, API, плагин и CDN

Ниже прайсы, проверенные 26.10.2026. Сервисы считают разные единицы: операции, объём исходников, уникальные преобразования или доставленные картинки. Поэтому сравнение по цене «за изображение» без определения единицы вводит в заблуждение. Мы не покупали тарифы и не оценивали качество облачных кодировщиков по нашей выборке.

У Imagify тариф при годовой оплате показан отдельно: Growth $4,99 и Infinite $9,99 в пересчёте на месяц. Это не помесячный платёж по сниженной цене. Бесплатный Starter даёт 20 МБ в месяц и ограничение 2 МБ на загружаемый файл. На маленьком сайте этого может хватить для пробы, но количество картинок зависит от их исходного веса.

У Tinify конвертация считается ещё одной операцией сверх исходного сжатия. Это прямо описано в справке API. Если загрузить 1000 исходников и для каждого запросить конверсию, модель даст 2000 операций. При свободном лимите 500 расчёт составит 1500, умноженные на $0,009, то есть $13,50. Без конвертации 1000 операций стоили бы $4,50. Эти суммы относятся к выбранному сценарию и свободному лимиту, а не к любым «1000 фото».

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

У Cloudflare внешние оригиналы и встроенное хранилище тарифицируются по-разному. На странице Images Pricing для хранилища указано $5 за 100 000 изображений в месяц и $1 за 100 000 доставок. Если обрабатываются изображения вне Images, применяется учёт преобразований. На бесплатном плане после лимита новые преобразования могут перестать выполняться, вместо автоматического платного перерасхода. В том же прайсе указано, что format и quality не учитываются при определении уникальности преобразования. Поэтому смена этих двух параметров сама по себе не удваивает число уникальных преобразований. У Tinify запрос конвертации, напротив, расходует дополнительную операцию.

Для нескольких посадочных страниц обычно достаточно локальной обработки. Репозиторий Squoosh поясняет, что само изображение обрабатывается на устройстве; при этом приложение использует аналитику. «Файл не отправляется на сервер сжатия» не равно «страница вообще не делает сетевых запросов». Для пакетного процесса удобнее утилиты и сохранённые настройки. Как расходы на инструменты складываются с остальной работой команды, разобрано в бюджете стека медиабайера.

Как заменить картинки и сохранить рабочий первый экран

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

1. Откройте ленд на телефоне и в настольном браузере. В Network выпишите картинки первого экрана и их размер передачи. Результат шага: список реально загруженных файлов, а не все файлы на сервере.
2. Создайте уменьшенные копии по ширине блока и плотности экрана. Результат: отдельные файлы для мобильного и широкого вариантов без растягивания маленького исходника.
3. Сохраните WebP и, если нужен дополнительный выигрыш, AVIF. Откройте оба рядом с оригиналом. Проверьте цену, упаковку и границы предмета. Отбросьте вариант, где детали мешают понять оффер.
4. Подключите выбранные файлы через picture или штатную функцию CMS. Оставьте резервный JPEG. Результат: браузер выбирает один подходящий источник, а ширина и высота блока остаются прежними.
5. Проверьте страницу с отключённым кешем и затем повторно с кешем. Отдельно протестируйте форму. Итог: изображения загружаются, верстка не скачет, заявка проходит привычным путём.

Пример ниже предназначен для блока шириной до 780 CSS-пикселей. Все перечисленные файлы должны существовать и иметь указанную ширину. Если контейнер уже, исправьте sizes под свою вёрстку. В MDN для picture объяснён выбор source по типу и условиям; запасной img нужен даже тогда, когда большинство посетителей поддерживают AVIF.

<picture>
  <source type="image/avif"
    srcset="/img/product-390.avif 390w, /img/product-780.avif 780w"
    sizes="(max-width: 780px) 100vw, 780px">
  <source type="image/webp"
    srcset="/img/product-390.webp 390w, /img/product-780.webp 780w"
    sizes="(max-width: 780px) 100vw, 780px">
  <img src="/img/product-780.jpg" width="780" height="520"
    alt="Товар на светлом фоне" fetchpriority="high">
</picture>

Пример относится к подключению файлов на странице. Высоту 520 замените реальной высотой своего изображения. Высокий приоритет задаётся картинке первого экрана, если она действительно важна для LCP. Fetch Priority это подсказка браузеру, поэтому назначать high всем картинкам бессмысленно. Остальные ресурсы всё равно конкурируют за сеть и обработку.

Для картинки LCP не ставьте loading=»lazy». В руководстве web.dev сказано: «Never lazy-load your LCP image». Для изображений ниже первого экрана отложенная загрузка может быть полезна; её поведение описано в справке browser-level lazy loading. Если ваш конструктор сам добавляет атрибуты, проверяйте итоговый DOM, то есть собранную браузером структуру страницы.

На WordPress не всегда нужен отдельный плагин только ради загрузки файла. Поддержка WebP появилась в WordPress 5.8, AVIF в версии 6.5. Но обработка AVIF зависит от библиотек хостинга. Откройте «Здоровье сайта», вкладку информации и раздел обработки медиафайлов. Затем загрузите одну тестовую картинку и убедитесь, что миниатюры создались. Проверьте и оригинал, и созданные миниатюры. Само ядро WordPress не создаёт из загруженного AVIF элемент picture с резервным JPEG: для такой схемы нужна поддержка темы, плагина или своя разметка.

В теме предпочтительнее wp_get_attachment_image, если она подходит вашему шаблону: функция умеет формировать атрибуты изображения, включая srcset и sizes. Самописный HTML с одним src не получает все варианты автоматически. На ленде внутри Keitaro и в статической папке эти атрибуты обычно приходится прописывать в шаблоне. В локальном лендинге найдите картинку по src в его HTML и замените файл в соответствующем каталоге ресурсов. Ответ трекера удобно проверить командой ниже, подставив публичный адрес своей картинки. Настройки кампании для этого менять не требуется.

curl -I https://example.com/assets/product.avif

Ожидается успешный ответ и Content-Type: image/avif. Затем откройте сам файл в браузере: проверка заголовков не подтверждает целостность изображения.

Если сервер выбирает WebP или AVIF по заголовку Accept и сохраняет один URL, проверьте кеш. Заголовок Vary сообщает кешу, по каким заголовкам различаются ответы. Без корректного разделения один посетитель может получить вариант, рассчитанный на другой браузер. Для небольшого ленда отдельные адреса и picture часто проще в проверке, чем скрытая подмена ответа.

Для файлов с новыми именами можно настроить длительное кеширование. Cache-Control описывает срок свежести и immutable; последний означает, что содержимое не изменится во время этого срока. Значит, после новой обработки лучше менять имя или версию URL. Иначе часть посетителей продолжит видеть предыдущую картинку, а сравнение двух вариантов станет ненадёжным.

Что проверить перед запуском платного трафика

Откройте Network с включённым Disable cache. Руководство Chrome DevTools объясняет, что это приближает загрузку к первому визиту. Отфильтруйте изображения и проверьте адрес, тип ответа и размер. Расширение в имени само по себе не доказывает формат: сервер может вернуть HTML ошибки даже по адресу с окончанием .webp.

На Nginx соответствие расширений и MIME задаётся через директиву types, на Apache через AddType и mod_mime. Не вставляйте случайный конфиг поверх рабочего: сначала посмотрите фактический Content-Type. Если браузер уже получает image/webp или image/avif и картинка отображается, дополнительная правка MIME не нужна.

В отчёте производительности обращайте внимание на Improve image delivery. Chrome оценивает потенциальную экономию байтов и указывает файлы для проверки. У нас нет данных о том, сколько посетителей дошло до формы после замены. Такие числа можно получить только на реальном трафике с корректным сравнением.

У рекламных площадок есть требования к работоспособности целевой страницы. Google Ads описывает недоступные и неправильно работающие страницы в правилах назначения. Из этой справки не следует требование «перевести всё в AVIF» или обещание пройти модерацию после сжатия. Формат картинки не заменяет доступность страницы и соответствие объявления содержимому.

Проверяйте прямую ссылку и ссылку с UTM-метками. Они не должны менять пути к ресурсам. Если ленд проходит через перенаправление или трекер, открывайте окончательный адрес из настоящей цепочки. Локальной проверки HTML недостаточно. Для PWA отдельно учитывайте кеш сервис-воркера: повторный просмотр способен скрыть проблему первой загрузки.

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

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

Что в итоге

Сначала подберите разрешение под блок и телефон. Для наших 12 JPEG AVIF дал меньший вес на каждом файле, а сочетание AVIF и ширины до 780 пикселей сократило общий объём на 73,8%. Этот вариант стоит проверить первым, если CMS и библиотеки его обрабатывают. WebP проще оставить там, где уже налажена его выдача или важна скорость подготовки большой очереди. Скриншоты с мелкими цифрами проверяйте отдельно. Сохраните исходники, подключите резервный формат и откройте ленд без кеша. После этого сравните на трафике загрузки целевой страницы и заявки: именно они покажут, оправдала ли замена затраты команды.