Notatki zespołu o rzemiośle, formatach i drobnych decyzjach stojących za dobrym wynikiem.
Dlaczego AVIF bije WebP na zdjęciach
Przewaga AVIF nad WebP w kompresji bierze się z kodeka pod spodem. WebP używa silnika pojedynczej klatki stworzonego pod wideo, lecz wciąganego do obrazów nieruchomych od 2010 roku. nowoczesnemu formatowi, kodek za AVIF, ukazał się w 2018 roku po latach badań wymierzonych wprost w granice i. nowoczesnemu formatowi stosuje bardziej agresywne podpróbkowanie chrominancji, drobniejszy podział bloku aż do 4 na 4 piksele i skuteczniejszy koder entropijny. Praktyczny wynik, potwierdzony analizą na dużych zestawach testowych ze zdjęciami, jest taki, że AVIF zwykle jest o 20 do 30 procent mniejszy od WebP przy tej samej jakości postrzeganej na zdjęciach. Na grafice generowanej komputerowo z płaskim kolorem i twardymi krawędziami różnica się zwęża, bo prostszy algorytm WebP dobrze radzi sobie z takimi wzorami. Dla każdej strony, której najcięższymi plikami są zdjęcia, przejście na AVIF ma wymierny wpływ na pasmo.
Drugie stratne przejście w praktyce
Gdy konwertujesz WebP na AVIF, i źródło, i wynik są stratne. WebP już zdecydował, którą informację koloru odrzucić, gdy powstawał, i te decyzje są trwałe: przejście na AVIF nie odzyska żadnej z nich. Część od AVIF podejmuje wtedy własne decyzje co do danych pikseli, które dostaje, przy jakości 85. Na zdjęciach łączny efekt dwóch stratnych przejść wciąż jest wizualnie niemal bezstratny przy typowych rozmiarach ekranu, mierzy około na prawdziwym materiale zdjęciowym. Na grafice już nadszarpniętej zapisem WebP drugie przejście może nawarstwić widoczne artefakty. Praktyczna zasada: jeśli źródłowy WebP wygląda czysto w rozmiarze, w jakim zamierzasz go pokazać, AVIF też będzie. Jeśli WebP już niesie szum kompresji, zbadaj AVIF dokładnie przed publikacją.
Jak warstwa przezroczystości przepływa na drugą stronę
WebP i AVIF zapisują przezroczystość jako osobną płaszczyznę alfa obok danych koloru. Konwersja czyta warstwa przezroczystości WebP, składa go przy pełnej przezroczystości, a potem oddaje części od AVIF, która zapisuje własną ścieżkę alfa kodowaniem pojedynczej klatki nowoczesnemu formatowi przy jakości 85. Miękkie gradienty przezroczystości, rozmyte krawędzie i częściowo przezroczyste obszary przechodzą tę podróż tam i z powrotem. Płaszczyzna alfa AVIF sama jest stratna przy jakości 85, co może wnieść ledwie zauważalne strzępienie na twardych krawędziach przy skrajnym powiększeniu. Przy normalnych rozmiarach podglądu w sieci różnica wobec źródła jest niewidoczna. Do pracy pikselowo dokładnej na małych ikonach, gdzie krawędź alfy musi być dokładna, trzymaj źródło WebP i sprawdź wynik przy pełnym powiększeniu, zanim go wyślesz.
Oczekiwania co do czasu zapisu na silnikach i urządzeniach
Część od AVIF rozgrzewa się raz na sesję przeglądarki, dokładając około sekundy do pierwszej konwersji. Potem Chromium daje najlepszą przepustowość: jakieś 40 milisekund na miniaturę 0,12 megapiksela, 250 milisekund na zdjęcie 1-megapikselowe, 2,8 sekundy na zdjęcie 4K i 25 sekund na pełny obraz 48-megapikselowy w najgorszym zaobserwowanym przypadku. Firefox to wyraźny wyjątek, prowadzący ten sam zapis około czterokrotnie wolniej, co stawia przypadek 4K blisko 31 sekund, a duże pliki poza dwie minuty. WebKit ląduje pośrodku, bliżej Chromium. Sprzęt mobilny idzie 3 do 5 razy wolniej od komputera na wszystkich silnikach. Do rutynowej konwersji plik po pliku Chrome na laptopie albo komputerze jest praktycznym narzędziem. Dla użytkowników Firefox z dużymi obrazami szczera rada to zmienić przeglądarkę albo zostać przy WebP.
Core Web Vitals a przejście na AVIF
Strony podające zdjęcia płacą pasmem za każdy załadowany obraz. Jeśli te obrazy są dziś w WebP, konwersja ich na AVIF tnie transfer na obraz o jakieś 20 do 30 procent na zdjęciach. Na stronie z bohaterskim obrazem WebP o wadze AVIF sprowadza go do około noticeably smaller. Na siatce produktów z dwunastoma miniaturami WebP po AVIF oszczędza około noticeably smaller łącznej wagi strony. Te oszczędności wprost dotykają Largest Contentful Paint, gdy elementem LCP jest obraz. Przy około 94 procentach globalnej obsługi AVIF element picture podający AVIF pierwszy z zapasowym WebP pokrywa niemal cały ruch. Koszt znaczników płaci się raz na komponent obrazu, a oszczędność pasma wraca przy każdym kolejnym załadowaniu strony.
Dlaczego konwersja na AVIF opiera się na serwerze
AVIF stoi na kodeku nowoczesnemu formatowi, tej samej rodzinie, której używa nowoczesne wideo, i jest celowo ciężki do utworzenia w zamian za zwarte pliki. Wykonanie tej pracy dobrze, zwłaszcza na dużych zdjęciach, jest dużo szybsze i pewniejsze na prawdziwym serwerze niż w przeglądarce telefonu, więc ta para wysyła obraz na nasz serwer, by stworzyć najlepszy możliwy AVIF. Plik jest przetwarzany, a wynik wraca do ciebie, i pobranie zostaje usunięte po około 2 godzinach, bez konta i bez długiego przechowywania. Konwersja kilku obrazów naraz zawsze działa na serwerze, który składa gotowy zestaw w jedno pobranie, skasowane w tym samym krótkim czasie. Jeśli naszego serwera nie da się osiągnąć, pojedyncza konwersja zaczyna powstawać w przeglądarce, ten plik zostaje lokalnie, godząc się na wolniejsze tworzenie dla wygody. Wymiana jest jasna: serwer kupuje jakość i tempo na formacie, który tego najbardziej potrzebuje, a twój plik nigdy nie jest trzymany dłużej niż krótkie okno samej konwersji.
