Notatki zespołu o rzemiośle, formatach i drobnych decyzjach stojących za dobrym wynikiem.
Krajobraz zgodności AVIF w 2026 roku
Obsługa AVIF w przeglądarkach osiągnęła do 2026 roku około 94,3 procent globalnych przeglądarek, ale obsługa w przeglądarkach to nie cały obraz. Duża część konsumpcji obrazów odbywa się poza przeglądarkami: klienty poczty renderujące osadzone obrazy, narzędzia projektowe otwierające pliki do edycji, systemy treści sprawdzające i przetwarzające ponownie przesyłki, ścieżki dostarczania obrazów, edytory dokumentów osadzające materiały i platformy społecznościowe przetwarzające obrazy w chwili przesyłania. W większości tych systemów spoza przeglądarki obsługa AVIF zauważalnie pozostaje w tyle za przyjęciem przeglądarkowym. Gmail, Outlook i większość firmowych klientów poczty wciąż prowadzą obrazy przez starsze ścieżki, które odrzucają AVIF. Adobe Creative Cloud dodał obsługę AVIF dopiero w wersjach z końca 2024 roku. Wiele konfiguracji WordPress ze starszymi wtyczkami obrazów wciąż blokuje AVIF przy przesyłaniu. WebP natomiast jest przyjęty na niemal wszystkich tych platformach od lat. Konwersja AVIF na WebP to most zgodności dla tej infrastruktury spoza przeglądarki.
Dlaczego konwersja jest szybka po obu stronach
Przewaga szybkości AVIF na WebP nad kierunkiem odwrotnym wynika z architektury kodeków. Dekodowanie AVIF realizuje natywny dekoder przeglądarki, który na nowoczesnych urządzeniach działa z akceleracją sprzętową. Zapis WebP korzysta z natywnych środków przeglądarki dla WebP, na większości platform także wspartych sprzętowo. Żadna z operacji nie musi wczytywać ciężkiego modułu, a to właśnie wąskie gardło przy tworzeniu AVIF. Środki do wyjścia w AVIF są duże i potrzebują około sekundy na uruchomienie w ramach sesji. AVIF na WebP omija to wszystko. Ścieżka dekoduje, a potem zapisuje natywnymi drogami, i pełna droga w obie strony dla zdjęcia 2-megapikselowego domyka się znacznie poniżej sekundy w dowolnej nowoczesnej przeglądarce na komputerze stacjonarnym lub laptopie. To czyni konwersję AVIF na WebP odpowiednią dla pracy interaktywnej, gdzie użytkownik oczekuje odpowiedzi w mniej niż sekundę.
Ile naprawdę kosztuje ponowny zapis
Konwersja AVIF na WebP obejmuje jeden krok ponownego zapisu. AVIF był pierwotnie utworzony z pewnym stopniem kompresji stratnej. Jego dekodowanie daje wartości pikseli odzwierciedlające to stratne źródło. Następnie środki WebP nakładają własną kompresję na te detale w ustawieniu niemal bezstratnym dostrojonym do jakości 85. Przy tym ustawieniu wyjście mierzy około 44 dB PSNR na typowej treści fotograficznej. Dla osoby oglądającej zdjęcie w normalnym rozmiarze wyświetlania różnica między źródłowym AVIF a wyjściowym WebP nie jest widoczna. Dla grafiki z bardzo drobnym tekstem w małych rozmiarach, ikon dokładnych co do piksela lub bloków barwnych o twardych krawędziach skumulowany efekt dwóch stratnych przejść może ujawnić subtelne różnice przy bliskim oglądaniu. Zanim przeniesiesz całą bibliotekę, przetestuj reprezentatywną próbkę przy pełnym powiększeniu na najbardziej wrażliwych na jakość materiałach.
Droga przezroczystości w obie strony w szczegółach
Przezroczystość w AVIF jest zakodowana w oddzielnej warstwie, którą przeglądarka dekoduje wraz z zawartością barwną podczas wczytywania pliku. Gdy przeglądarka dekoduje AVIF, wytwarza zarówno bufor barwny, jak i maskę alfa. Konwersja składa oba przy pełnej przezroczystości, zachowując każdy częściowo przezroczysty detal. Następnie środki WebP zapisują stratny WebP z osobnym kanałem alfa zakodowanym bezstratnym algorytmem WebP właśnie dla płaszczyzny alfa. W efekcie maska przezroczystości wyjściowego WebP jest przechowywana bezstratnie względem wartości alfa zdekodowanych z AVIF. Miękkie gradienty i rozmyte krawędzie przetrwają. Jedyna obecna degradacja alfy to ta, którą wprowadziło pierwotne kodowanie AVIF. Jeśli źródłowy AVIF ma czyste krawędzie alfy, wyjściowy WebP też je ma, a maska jest gotowa do nałożenia na dowolne tło.
Zestawienie wyjścia z alternatywami
Gdy chcesz uczynić AVIF zgodnym z systemem, który nie czyta AVIF, masz trzy realne wybory: konwersję na WebP, na PNG albo na JPG. JPG to zły wybór dla czegokolwiek z przezroczystością, bo nie ma kanału alfa i spłaszcza ją do jednolitego koloru. PNG tworzy najcięższy plik, zwykle trzy do dziesięciu razy większy od AVIF, i ma sens tylko wtedy, gdy potrzebujesz bezstratnego materiału pośredniego albo cel wymaga wprost PNG. WebP stoi pośrodku: daje uniwersalną nowoczesną zgodność, zachowuje przezroczystość i tworzy plik zwykle o 20 do 25 procent większy od AVIF, a nie o 300 do 1000 procent jak PNG. Dla każdej konwersji dla zgodności, która nie wymaga wyjścia bezstratnego, WebP jest właściwym formatem pośrednim.
Jeden w przeglądarce, partie na serwerze
Ta para idzie na dwa sposoby zależnie od zadania. Pojedynczy AVIF jest dekodowany i zapisywany na nowo jako WebP całkowicie wewnątrz twojej przeglądarki natywnymi drogami, więc dla jednego pliku nie ma żadnej wysyłki, potwierdzone zerową liczbą żądań wychodzących po załadowaniu strony. To właściwa droga dla czegoś szybkiego i dla poufnej pracy klienta, własnych zdjęć produktowych czy dokumentów, które wolisz trzymać na swojej maszynie. Konwersja kilku plików naraz dzieje się na naszym serwerze, bo grupowanie, pakowanie i dostarczanie zestawu to zadanie, które serwer robi dobrze: pliki wjeżdżają, są kodowane, pakowane i oddawane jako jedno pobranie, które znika po około 2 godzinach, bez długiego przechowywania. W praktyce: pojedyncza konwersja pozostaje na urządzeniu, a partia jest przetwarzana zdalnie, ale trzymana tylko przez krótkie okno, które bierze pobranie.
