Заметки команды о мастерстве, форматах и небольших решениях, стоящих за хорошим результатом.
Почему AVIF берёт верх над WebP на фотографиях
Преимущество AVIF в сжатии над WebP идёт от кодека внутри. WebP использует движок одиночного кадра созданный для видео, но применяемый к неподвижным снимкам с 2010 года. современному формату, кодек за AVIF, вышел в 2018 году после лет исследований, нацеленных прямо на пределы и. современному формату применяет более агрессивную субдискретизацию цветности, более тонкое разбиение блоков вплоть до 4 на 4 пикселя и более эффективный энтропийный кодер. Практический итог, подтверждённый анализом на больших наборах фотоснимков, в том, что AVIF обычно на 20 до 30 процентов меньше WebP при том же воспринимаемом качестве на фотографиях. На сгенерированной компьютером графике с плоским цветом и резкими краями разрыв тает, потому что более простой алгоритм WebP хорошо справляется с такими узорами. Для любой страницы, чьи самые тяжёлые файлы это фотографии, переход на AVIF даёт измеримый эффект для трафика.
Второй проход с потерями на практике
Когда вы конвертируете WebP в AVIF, и источник, и результат с потерями. WebP уже решил, какую цветовую информацию отбросить при своём создании, и эти решения постоянны: переход в AVIF не вернёт ни одного из них. Часть для AVIF затем принимает свои решения о пиксельных данных, что получает, при качестве 85. Для фотографий совокупный эффект двух проходов с потерями всё ещё визуально почти без потерь при типичных размерах экрана, измеряет около 42 дБ на реальном фотоматериале. Для графики, уже подпорченной записью WebP, второй проход может нагромоздить видимые артефакты. Практическое правило: если исходный WebP выглядит чисто в том размере, в каком вы собираетесь его показывать, AVIF тоже будет. Если WebP уже показывает шум сжатия, изучите AVIF внимательно перед публикацией.
Как альфа-канал проходит насквозь
И WebP, и AVIF записывают прозрачность как отдельную альфа-плоскость рядом с цветовыми данными. Конвертация читает альфа-канал WebP, собирает его при полной прозрачности, затем передаёт части для AVIF, которая пишет свою альфа-дорожку через кодирование одиночного кадра современному формату при качестве 85. Мягкие градиенты прозрачности, размытые края и частично прозрачные области проходят это путешествие туда и обратно. Альфа-плоскость AVIF сама с потерями при качестве 85, что может внести едва заметную бахрому на резких краях при экстремальном увеличении. При обычных размерах просмотра в вебе разница с источником не видна. Для пиксельно точной работы на мелких иконках, где край альфы должен быть точным, держите источник WebP и проверьте результат при полном увеличении перед отправкой.
Ожидания по времени записи на разных движках и устройствах
Часть для AVIF разогревается раз за сеанс браузера, добавляя около секунды к первой конвертации. После этого Chromium даёт лучшую пропускную способность: примерно 40 миллисекунд для миниатюры 0,12 мегапикселя, 250 миллисекунд для фото в 1 мегапиксель, 2,8 секунды для фото 4K и 25 секунд для полного изображения в 48 мегапикселей в худшем наблюдаемом случае. Firefox оказывается заметным исключением, прогоняя ту же запись примерно вчетверо медленнее, что ставит случай 4K к 31 секунде, а крупные файлы за две минуты. WebKit располагается между ними, ближе к Chromium. Мобильное железо идёт в 3 до 5 раз медленнее десктопа на всех движках. Для рутинной конвертации файл за файлом Chrome на ноутбуке или десктопе остаётся практичным инструментом. Для пользователей Firefox с крупными изображениями честный совет это сменить браузер или остаться на WebP.
Core Web Vitals и переход на AVIF
Страницы, отдающие фотографии, платят трафиком за каждое загруженное изображение. Если эти изображения сейчас WebP, конвертация их в AVIF режет передачу на изображение примерно на 20 до 30 процентов на фотографиях. На странице с главным изображением WebP в 200 КБ AVIF приводит его примерно к 140 до 160 КБ. На сетке товаров с двенадцатью миниатюрами WebP по 30 КБ AVIF экономит около 70 до 90 КБ общего веса страницы. Эта экономия напрямую влияет на Largest Contentful Paint, когда элемент LCP оказывается изображением. При примерно 94 процентах глобальной поддержки AVIF в браузерах элемент picture, отдающий AVIF первым с запасным WebP, покрывает почти весь трафик. Стоимость разметки оплачивается раз на компонент изображения, а экономия трафика повторяется при каждой загрузке страницы после.
Почему конвертация в AVIF опирается на сервер
AVIF построен на кодеке современному формату, той же семье, что и современное видео, и намеренно тяжёл для создания в обмен на компактные файлы. Сделать эту работу хорошо, особенно на крупных фото, на настоящем сервере намного быстрее и надёжнее, чем в браузере телефона, поэтому эта пара отправляет изображение на наш сервер, чтобы создать лучший возможный AVIF. Файл обрабатывается, результат возвращается к вам, а скачивание убирается примерно за 2 часа, без учётной записи и без долгого хранения. Конвертация нескольких изображений сразу всегда идёт на сервере, который собирает готовый набор в одно скачивание, удаляемое в тот же короткий срок. Если до нашего сервера не достучаться, одиночная конвертация начинает создаваться в браузере, этот файл остаётся локальным, принимая более медленное создание ради удобства. Размен ясен: сервер покупает качество и скорость на формате, которому это нужнее всего, а ваш файл никогда не хранится дольше короткого окна самой конвертации.
