AVIF

AVIF er et moderne billedformat baseret på AV1-billedkodning og har filendelsen .avif. Formatet er udviklet af Alliance for Open Media og er designet til at lagre billeder effektivt med både tabsgivende og tabsfri komprimering. Det kan bruges til almindelige fotografier, grafik med transparens og mere avancerede billeder med høj bitdybde og HDR.

AVIF skal ikke forveksles med selve AV1-videoformatet. AVIF bruger AV1-billeddata i en billedcontainer baseret på HEIF/ISOBMFF-strukturen. For den almindelige webredaktør er detaljen ikke det vigtigste, men den forklarer, hvorfor formatet kan håndtere mere end bare et enkelt komprimeret foto.

I praksis konkurrerer AVIF især med JPEG/JPG og WebP på hjemmesider. JPEG er ekstremt udbredt og enkelt, WebP kombinerer moderne komprimering med god kompatibilitet, mens AVIF kan give meget effektiv komprimering og understøtter funktioner som transparens, højere bitdybder, wide color gamut og HDR.

Det betyder ikke, at AVIF altid er den mindste fil eller automatisk ser bedst ud. Resultatet afhænger af motivet, encoder, kvalitetsindstilling, dimensioner og hvilke funktioner der bruges. Et dårligt komprimeret AVIF kan være større eller se dårligere ud end en veldesignet JPEG eller WebP. Formatet er et værktøj, ikke en genvej rundt om billedoptimering.

WordPress har understøttet AVIF som medieformat siden version 6.5, når serverens billedbehandlingsmiljø understøtter det. Det gør AVIF relevant for almindelige WordPress-sites, men webhotellets ImageMagick- eller GD-opsætning kan stadig være afgørende for, om WordPress kan generere thumbnails og andre billedstørrelser korrekt.

AVIF er også understøttet i nyere versioner af Adobe Photoshop som import- og eksportformat. Det gør det lettere at få formatet ind i en normal grafisk arbejdsgang, men den redigerbare master bør stadig ofte være PSD, TIFF eller en anden arbejdsfil. AVIF er primært et leveringsformat, ikke nødvendigvis stedet hvor det kreative arbejde skal gemmes.

Til en hjemmeside er styrken især forholdet mellem visuel kvalitet og filstørrelse. Mindre billeder kan reducere den mængde data, browseren skal hente. Det kan være relevant for performance og dermed også for brugeroplevelsen, især på mobil eller langsommere forbindelser.

Det er derfor mere fornuftigt at sammenligne formater på rigtige billeder end at beslutte, at hele mediebiblioteket skal være AVIF alene på grund af navnet “next-gen”.

Den bedste måde at indføre AVIF på er som en del af et almindeligt billedworkflow. Start med den bedst mulige masterfil, beskær og skaler billedet til den størrelse, det faktisk skal bruges i, og eksportér derefter en AVIF-version med en kvalitet, der ser rigtig ud ved den forventede visningsstørrelse.

En praktisk proces kan være:

1. Bevar originalen eller den redigerbare master i RAW, PSD eller TIFF.
2. Bestem den maksimale pixelbredde, billedet behøver på hjemmesiden.
3. Eksportér en AVIF-version og en relevant sammenligningsfil, typisk WebP eller JPEG.
4. Sammenlign filstørrelse og visuel kvalitet på det faktiske motiv.
5. Kontrollér transparens og farver, hvis grafikken kræver det.
6. Upload filen og tjek, at CMS'et genererer de nødvendige størrelser.
7. Test frontend på mobil og desktop og kontrollér, at det rigtige billede faktisk bliver leveret.

Hvis du bruger WordPress, bør du tjekke under Site Health, om serverens mediehåndtering understøtter AVIF, hvis din WordPress-version og hosting stadig er afhængig af server-side billedbehandling. Det er ikke nok, at browseren kan vise filen. WordPress skal også kunne håndtere upload, beskæring og generering af mellemstørrelser.

AVIF kan bruges til fotografier, men også til billeder med alpha-transparens. Det gør formatet interessant som alternativ til PNG i nogle situationer. Men UI-elementer, logoer og enkle illustrationer kan stadig være bedre som SVG, fordi SVG er vektorbaseret og kan skaleres uden at være et rasterbillede.

På en webshop eller en billedtung serviceside bør AVIF ikke vurderes isoleret. Billeddimensioner, responsive images, lazy loading og komprimeringskvalitet betyder mindst lige så meget. Et 4000 pixels bredt AVIF-foto er stadig unødvendigt tungt, hvis det vises 700 pixels bredt. Formatet kan ikke kompensere for en forkert dimension.

Derfor bør AVIF kobles til almindelig hastighedsoptimering og teknisk kvalitet. På en ny løsning kan vi vælge billedformat og leveringsstrategi som en del af webudviklingen i stedet for at installere endnu et plugin efter lancering og håbe, at det løser alle billeder automatisk.

Hvis en platform skal understøtte gamle klienter eller eksterne integrationer med snævre formatkrav, kan det være nødvendigt med fallback. Det kan ske gennem serverlogik, billed-CDN eller HTML's picture-element, hvor browseren får flere formater at vælge mellem. På moderne sites er ren AVIF-brug ofte mulig, men kompatibilitet bør stadig vurderes ud fra målgruppen og systemerne omkring siden.

Forestil dig en webshop med store produktfotos. Den oprindelige master er et højopløst TIFF-billede. Webshoppen viser produktbilledet op til 1200 pixels bredt. Den gamle fil er en JPEG på 320 KB.

Designeren laver først en korrekt 1200-pixels version og eksporterer både JPEG, WebP og AVIF ved kvaliteter, der visuelt ligger tæt på hinanden. AVIF-versionen ender i dette eksempel på 150 KB, WebP på 185 KB og JPEG på 260 KB. Tallene er kun et regneeksempel; et andet motiv eller en anden encoder kan give en anden rækkefølge.

AVIF vælges til de browsere og systemer, der håndterer formatet stabilt. Produktets thumbnail genereres samtidig i mindre størrelser, så mobilen ikke henter 1200-pixels billedet, hvis der kun er brug for 480 pixels.

På en produktside med seks billeder betyder det, at formatet kun er én del af besparelsen. De rigtige responsive størrelser reducerer også dataforbruget. Samlet bliver siden mærkbart lettere uden at produktbillederne ser ud som om de er blevet kørt gennem en aggressiv kompressor.

Hvis det samme foto senere skal bruges i en brochure, går man ikke tilbage til AVIF-filen. Man tager masteren og laver en version til tryk. Webfilen er optimeret til browseren; den er ikke den nye original.

Den største faldgrube er at gøre filformatet til hele performance-strategien. Et plugin kan konvertere JPEG til AVIF, men hvis temaet stadig serverer alt for store dimensioner eller preload'er billeder, der ikke er synlige, er gevinsten begrænset.

En anden fejl er at bruge samme kvalitetsværdi som i JPEG og forvente samme visuelle resultat. Kvalitetsskalaer er ikke direkte sammenlignelige mellem codecs. “80” i én encoder svarer ikke nødvendigvis til “80” i en anden. Sammenlign med øjnene og mål filstørrelsen.

Serverunderstøttelse kan også give overraskelser. En browser kan godt vise en uploadet AVIF-fil, mens WordPress ikke kan lave thumbnails, hvis serverens billedbibliotek mangler den nødvendige støtte. Derfor skal hele kæden testes: upload, redigering, mellemstørrelser og frontend.

Farver er endnu et område, hvor man bør kontrollere resultatet. AVIF kan bære avanceret farveinformation, men det betyder ikke, at alle skærme, programmer og eksportindstillinger gengiver den identisk. Til almindelige webprojekter bør farveworkflowet være bevidst og så enkelt som opgaven tillader.

Undgå også at konvertere små ikoner og logoer mekanisk til AVIF. Hvis grafikken allerede fungerer bedre som SVG eller en lille PNG, kan en rasterkonvertering være et skridt tilbage. Vælg format efter motivet.

AVIF-specifikationen understøtter både SDR, HDR, wide color gamut, alpha-transparens og billedsekvenser. Mange websites bruger kun en lille del af disse muligheder, men de forklarer, hvorfor formatet er mere end “en JPEG med bedre komprimering”.

Formatet er baseret på AV1-billeddata i en HEIF-baseret container. Det er en teknisk detalje, men den er nyttig, når værktøjer eller servere omtaler codec, container og MIME-type hver for sig. Den normale MIME-type er image/avif.

AVIF giver især mening, når der er mange store rasterbilleder. På en teksttung side med ét lille foto bliver gevinsten sjældent afgørende. På en webshop, ejendomsside eller portfolio med mange billeder kan den samlede datamængde derimod blive markant påvirket af formatvalget.

Brug AVIF sammen med Core Web Vitals-arbejde, men husk at Core Web Vitals ikke belønner et bestemt filformat. Det, der tæller, er den faktiske brugeroplevelse: hvor hurtigt det relevante indhold vises, hvor stabil siden er, og hvor hurtigt den reagerer.

Den bedste løsning er derfor ikke nødvendigvis “AVIF overalt”. Det er en billedpipeline, hvor originalen bevares, de rigtige dimensioner genereres, et passende format vælges, og resultatet testes i den virkelige side.