AVIF срещу JPEG XL: Сблъсъкът на форматите, който всеки разработчик трябва да познава

Оптимизацията на изображенията си остава един от най-високоефективните начини за подобряване на производителността на който и да е уебсайт. Една разлика от 100KB на изображение се натрупва бързо, когато обслужваш хиляди посещения. Затова когато JPEG XL най-накрая получи широкоразпространена поддръжка в браузърите, общността от разработчици разбираемо се развълнува. Най-накрая модерен формат с по-добро компресиране! Само че... реалността е по-нюансирана от маркетинговите обещания.

Прекарах доста време в ровене из най-новите бенчмаркове, сравняващи AVIF и JPEG XL в реални сценарии. Ето какво показват данните — и какво означава това за твоя следващ проект.

Обобщение за заетите разработчици

Ако оптимизираш за размер на файлове при нива на качество, подходящи за уеб доставка, AVIF последователно надминава JPEG XL. При стандартни настройки на качество, JPEG XL произвежда файлове с 15–25% по-големи от еквивалентни AVIF кодирания. Ако натиснеш и двата енкодера до максимални усилия, разликата намалява до 6–20%, но AVIF все още печели в повечето случаи.

Енкодерът, който избереш, има огромно значение. Не всички JPEG XL енкодери са еднакви. По-новият jixel енкодер обикновено произвежда по-малки файлове от libjxl — традиционната референтна имплементация. Въпреки това това предимство изчезва — и дори се обръща — при изображения с прозрачност.

Скрийншотове и илюстрации: AVIF доминира

Тук разликата става драстична. За скрийншотове, UI макети и векторни илюстрации, AVIF смазва JPEG XL с маржове, които биха те накарали да се замислиш, преди да избереш новия формат по подразбиране.

При настройки по подразбиране, еквивалентните JPEG XL файлове са с 30–90% по-големи. Ако максимизираш и двата формата, JPEG XL все още е с 20–70% по-голям. Много разработчици смятат, че имат нужда от беззагубни формати за този тип съдържание, но AVIF с повече загуби се справя забележително добре със скрийншотове. Визуалното качество при разумни нива на компресия е отлично.

Ако приложението ти включва скрийншотове на табла, документация или дизайн визуализации, AVIF трябва да е твоят избор по подразбиране.

Прозрачност: Сложна картина

Поддръжката на прозрачност се различава значително между форматите и енкодерите. AVIF се справя с прозрачността при компресия със загуби, запазвайки разумни размери на файловете. JPEG XL енкодерът libjxl произвежда файлове с 31–44% по-големи при настройки по подразбиране и шокиращи 61–70% по-големи при максимални усилия в сравнение с AVIF.

jixel подхожда към прозрачността различно — той кодира алфа каналите без загуби по подразбиране. Това звучи като предимство за качеството, но файловете се оказват 2–3 пъти по-големи от еквивалентните AVIF. Понякога беззагубният вариант не е правилният отговор.

Скорост на кодиране и памет: Реалните компромиси

Производителността има значение, когато обработваш стотици или хиляди изображения по време на build pipeline-а си. AVIF обикновено кодира по-бързо, използвайки по-малко памет, което се превежда директно в по-бързи CI/CD билдове и по-ниски разходи за изчисления.

jixel изненадва тук — всъщност кодира по-бързо от AVIF с по-ниска употреба на памет. Но не забравяй, че тези по-бързи кодирания обикновено произвеждат по-големи файлове. Ефективността в скоростта се изяжда от загубите в компресията. Когато сметнеш общите байтове, доставени на потребителите, AVIF остава по-добрият избор.

Декодиране: Където наистина има значение

Потребителите се интересуват от това колко бързо се зареждат страниците, не колко бързо работи build pipeline-ът им. Скоростта на декодиране влияе на Time to Interactive, и тук AVIF печели отново. JPEG XL обикновено отнема 2–3 пъти повече време за декодиране при средни настройки на качество.

Интересното е, че разликата намалява при много високи нива на качество, където Chrome понякога декодира JPEG XL по-бързо. Но за типичните уеб настройки на качество, AVIF декодира по-бързо, което означава по-бързо зареждане на страниците за посетителите ти.

Въпросът с нивата на усилие

Не всички quality presets са еднакви. По-високите нива на усилие (по-бавно кодиране, повече опити за компресия) си струват компромиса и за AVIF, и за jixel — те доставят забележимо по-добри резултати. Въпреки това, по-високите нива на усилие при libjxl са съвсем различна история.

Максималният режим на усилие при libjxl е драматично по-бавен и използва значително повече памет, докато понякога произвежда файлове, които са дори по-големи от настройките по подразбиране. Ако използваш libjxl, остани с усилие по подразбиране. Ако искаш по-добра JPEG XL компресия, използвай jixel вместо това.

HDR: Назряваща тема

High Dynamic Range съдържанието поставя различни предизвикателства. Поддръжката на gain map в JPEG XL — технологията, която позволява HDR заедно със стандартни дисплеи — все още не се поддържа от браузърните декодери. Инструментите за кодиране остават експериментални.

AVIF се справя с HDR по-зряло, макар че нито един формат не предлага перфектно решение за доставяне на HDR съдържание, което грациозно се връща към стандартни дисплеи. Засега HDR в мрежата си остава специализиран случай, изискващ внимателна имплементация.

Ъгълът с JPEG съвместимостта

JPEG XL предлага нещо уникално: обратна съвместимост със съществуващи JPEG файлове. Можеш да конвертираш наследени JPEG изображения в JPEG XL и да постигнеш 9–20% по-малки файлове без никаква загуба на качество. Форматът включва инструменти за това конвертиране.

Това има значение, ако разполагаш с голяма библиотека от съществуващи изображения. 15% намаление върху хиляди наследени изображения може да се преведе в сериозни спестявания на bandwidth.

Беззагубно: Където JPEG XL блести

За редките случаи, когато наистина се нуждаеш от беззагубна компресия, JPEG XL е ясният победител. Беззагубният WebP е с 9–17% по-голям за фотографии, а беззагубният AVIF е с 30–120% по-голям от еквивалентните JPEG XL файлове.

Въпреки това беззагубните изображения почти никога не са правилният избор за уеб доставка. Наказанието в размер на файл рядко оправдава ползите за качеството. Ако показваш беззагубни изображения в уеб страници, премисли. Ако трябва, бъди внимателен с по-високите нива на усилие при jixel — енкодерът понякога произвежда файлове, които са мъчително бавни за декодиране.

Какво означава това за твоите проекти

Ето моята практическа препоръка: използвай AVIF с 4:4:4 chroma subsampling при максимални нива на усилие по подразбиране. Ползите за качеството си струват по-бавното кодиране, а предимствата в размер на файловете спрямо JPEG XL са съществени в повечето случаи на употреба.

Въпреки това, тествай със собствените си изображения. Бенчмарковете показват аутлаери, където JPEG XL се представя сравнимо или дори по-добре. Ако работиш със специфични типове изображения, с които AVIF сякаш се справя зле, опитай jixel-кодиран JPEG XL и сравни.

И двата формата са се подобрили драматично наскоро. Това, което изглежда като правилният избор днес, може да се промени след шест месеца. Ландшафтът на форматите продължава да се развива бързо.

По-голямата картина

Оптимизацията на изображения не е само избор на формат. Тя включва build pipelines, CDN конфигурация, responsive изображения и lazy loading стратегии. Изборът на формат е един лост сред много.

За разработчиците, използващи Vibe Hosting на NameOcean, добрата новина е, че модерната хостинг инфраструктура поддържа тези формати нативно. Компресията се случва веднъж по време на deploy; ползите за производителността текат автоматично към всеки посетител.

Не позволявай на нерешителността относно форматите да парализира усилията ти за оптимизация. AVIF е по-сигурният избор днес. Но остани информиран — войните на форматите за изображения далеч не са приключили, а конкуренцията движи подобренията, от които всички се възползваме.

Какви формати за изображения използваш в текущите си проекти? Експериментирал ли си с AVIF или JPEG XL? Бих се радвал да чуя за преживяванията ти в коментарите.