Бележки от екипа за майсторството, форматите и малките решения зад добрия резултат.
Защо AVIF бие WebP при снимки
Предимството на AVIF при свиване пред WebP идва от кодека отдолу. WebP ползва интракадровия двигател проектиран за видео, но използван за неподвижни изображения от 2010. съвременен формат, кодекът зад AVIF, излезе през 2018 след години изследвания, насочени право към ограниченията на и. съвременен формат прилага по-агресивна цветова подизвадка, по-фино делене на блокове до 4 на 4 пиксела и по-ефективен ентропиен кодиращ модул. Практическият резултат, потвърден с анализ по върху големи набори от тестови снимки, е, че AVIF обикновено е с 20 до 30 процента по-малко от WebP при същото възприемано качество при снимки. При генерирана от компютър графика с плосък цвят и резки ръбове разликата се стеснява, защото по-простият алгоритъм на WebP се справя с тези шаблони ефективно. За всяка страница, чиито най-тежки файлове са снимки, надграждането към AVIF има измеримо въздействие върху честотната лента.
Второто преминаване със загуби на практика
Когато преобразувате WebP към AVIF, и източникът, и изходът са със загуби. Запазването на WebP вече е решило коя цветова информация да изхвърли, когато WebP е било първоначално създадено, и тези решения са постоянни: преобразуването към AVIF не може да възстанови нищо от тях. После запазването на AVIF взема собствените си решения за пикселните данни, които получава, при качество 85. За снимки комбинираният ефект от две преминавания със загуби остава визуално почти без загуби при типични размери на показване, измервайки при реално снимково съдържание. За графика, вече влошена от своето 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 от, AVIF го свежда до около noticeably smaller. На продуктова мрежа с дванадесет миниатюри WebP от, AVIF спестява около noticeably smaller от общото тегло на страницата. Тези икономии пряко влияят на Largest Contentful Paint, когато елементът на LCP е изображение. При около 94 процента глобална поддръжка на браузъри за AVIF, елемент picture, който сервира AVIF на първо място с резервно WebP, покрива практически целия трафик. Разходът за маркиране се плаща веднъж на компонент за изображение, а икономията на честотна лента се повтаря при всяко следващо зареждане на страницата.
Защо преобразуването към AVIF се обляга на сървър
AVIF стъпва върху кодека съвременен формат, същото семейство, което ползва модерното видео, и нарочно е тежък за създаване в замяна на компактни файлове. Да се свърши тази работа добре, особено при големи снимки, на истински сървър е далеч по-бързо и по-надеждно, отколкото в браузъра на телефон, затова тази двойка изпраща изображението към нашия сървър, за да създаде най-добрия възможен AVIF. Файлът се обработва, резултатът се връща при вас, а изтеглянето се премахва за около 2 часа, без акаунт и без дълготрайно съхранение. Преобразуването на няколко изображения наведнъж винаги върви на сървъра, който сглобява готовия комплект в едно изтегляне, изтрито в същия кратък срок. Ако нашият сървър не може да бъде достигнат, едно преобразуване започва да се създава в браузъра, този файл остава локален, приемайки по-бавно създаване заради удобството. Размяната е ясна: сървърът купува качество и скорост за формата, който се нуждае най-много от това, а вашият файл никога не се пази извън краткия прозорец, който отнема преобразуването.
