Нотатки від команди про майстерність, формати та невеликі рішення, що стоять за добрим результатом.
Чому 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 години, без особистих даних і без тривалого зберігання. Конвертація кількох зображень одразу завжди іде на сервері, який збирає готовий набір в одне завантаження, видалене в той самий короткий строк. Якщо до нашого сервера не достукатися, одна конвертація починає створюватися в браузері, цей файл лишається локальним, приймаючи повільніше створення заради зручності. Розмін ясний: сервер купує якість і швидкість на форматі, якому це найпотрібніше, а ваш файл ніколи не зберігається довше за коротке вікно самої конвертації.
