WebP en AVIF: goede beelden leveren zonder oude browsers kapot te maken

Het nieuwe ontwerp schakelt alle banners over naar AVIF: spectaculaire Lighthouse-versterking. Behalve dat de interne CRM van de klant nog steeds gericht is op Safari 14 op enterprise macOS: een eenvoudig <img src="hero.avif"> geeft een grijs vierkant weer. De support spreekt van een “broken site”; marketing spreekt over ‘modernisering’. Beide bevinden zich precies op hun perimeter.

WebP en AVIF verminderen het gewicht zonder de waargenomen kwaliteit op te offeren — als de levering progressief blijft: beter formaat voor capabele browsers, universele fallback voor anderen. Het moderniseren van de beeldverhouding is geen vakje dat moet worden gecontroleerd; het is een leveringscontract met uw echte publiek.

Browserondersteuning en beeldstrategie

Het element <picture> blijft de meest voorspelbare benadering aan de oorsprongskant:

<afbeelding>

  <source srcset="hero.avif" type="image/avif">

  <source srcset="hero.webp" type="image/webp">

  <img src = "held.jpg" alt = "Beschrijving" breedte = "1200" hoogte = "630">

</foto>

Vul altijd width en height in op de img-tag — dit voorkomt lay-outverschuiving (CLS). Het alt attribuut moet op de fallback-afbeelding blijven staan; dit is wat crawlers en schermlezers als laatste redmiddel gebruiken.

Alleen AVIF aanbieden betekent optimaliseren voor Lighthouse en tegelijkertijd de daadwerkelijke browservloot vergeten – vaak B2B-klanten met een hoog gemiddeld winkelmandje.

CDN, Accepteer en Varieer onderhandeling

Een CDN die over het formaat onderhandelt via de Accept: image/avif,image/webp,/ header vereenvoudigt de HTML, maar legt Vary: Accept en een correcte cachesleutel op. Zonder Vary kan het CDN een AVIF naar een incompatibele browser sturen.

Op een CDN-loze oorsprong blijft <picture> voorspelbaarder dan een ondoorzichtige herschrijving op de server. Onder WordPress genereren de ShortPixel- of Imagify-plug-ins de variaties. Controleer of de fallback wordt weergegeven in het beheerdersvoorbeeld en in een oude Safari.

Stem dit beleid af op uw cache headers: Afbeeldingen die door Accept zijn onderhandeld, vereisen een consistent Vary-beleid tussen oorsprong en edge.

Kwaliteit, afmetingen en srcset

Serveer meerdere resoluties via srcset en sizes voor mobiel. AVIF-kwaliteit op 50 is visueel vaak gelijkwaardig aan JPEG op 80 – pas aan per asset, niet met een globale instelling.

Vermijd vergroting: wijzig het formaat van de bron, comprimeer een 4000 px-bestand dat in 400 px wordt weergegeven niet via CSS. Logo's blijven in SVG — niet in AVIF.

Voor banners met verschillende bijsnijdingen voor mobiel/desktop maakt het kenmerk media op <bron> art direction mogelijk zonder de hele pagina te dupliceren.

Conversiepijplijn: bouwen of direct

Statische build (Sharp, Squoosh, ImageMagick in CI) is geschikt voor bekende assets: helden, iconen, marketingvisuals. Genereer AVIF, WebP en JPEG van een PNG- of TIFF-master. Naam met hash + Cache-Control long.

On-the-fly conversie (imgproxy, Cloudflare Polish, speciale beeldservice) past zich aan aan gebruikersuploads in e-commerce of CMS. Asynchroon coderen: een upload hoeft geen dertig seconden te wachten op AVIF-conversie. Het resultaat agressief in de cache opslaan.

Toegankelijkheid en SEO-afbeeldingen

Het beschrijvende kenmerk 'alt' blijft op de fallback-tag 'img' staan. Voor decoratieve afbeeldingen: alt="" expliciet. Stabiele URL's en een sitemap met afbeeldingen helpen bij het indexeren. Google leest WebP en AVIF, maar JPEG-fallback stelt conservatieve crawlers gerust.

Verwijder de JPEG niet "omdat niemand deze gebruikt" zonder te meten: analyses en serverlogboeken laten vaak een onderschatte verouderde wachtrij zien.

De top: modern formaat, exclusief publiek

Dit is wat de Lighthouse-score niet meet.

Goede afbeeldingen = onderhandeling over het formaat plus fallback plus dimensies — niet één enkel MIME-type wordt aan iedereen opgelegd.

Beslis en ga vooruit zonder blinde vlek

Vóór de volgende visuele revisie:

1. Implementeer <picture> met AVIF-, WebP- en JPEG-fallback op hero-visuals.
2. Configureer srcset en sizes voor responsief: breedte/hoogte op elke img.
3. Kies statische build of directe conversie, afhankelijk van de bron van de afbeeldingen (marketing versus CMS-uploads).
4. Controleer Varieer: Accepteer als het CDN over het formaat onderhandelt – kruisverwijzing met het cachebeleid.
5. Test op Safari 14, Edge legacy en met JavaScript uitgeschakeld: blijven hero-afbeeldingen zichtbaar?
6. Vergelijk Image CDN en hosting via de overzicht en de vergelijker.

Voor statische items gaat u naar HTTP/2: minder gewicht per afbeelding vermenigvuldigt het effect van multiplexing.

Veelgestelde vragen

AVIF of WebP als prioriteit?

AVIF comprimeert beter (vaak 20-50% minder dan WebP) maar codeert langzamer en heeft iets nieuwere ondersteuning. WebP blijft een uitstekend compromis. Serveer AVIF als eerste bron, WebP als tweede, JPEG als fallback via <picture>.

Hoe serveer ik het juiste formaat?

Via <picture> met de tags <source type="image/avif"> en <source type="image/webp">, plus een <img src="...jpg"> fallback. Alternatief: CDN onderhandelt over de Accept-header — met Vary: Accept en aangepaste cachesleutel.

En beeld-SEO?

Bewaar een beschrijvende 'alt' op de reserveafbeelding, stabiele URL's en een sitemap voor afbeeldingen. Google indexeert WebP en AVIF; JPEG-fallback stelt de meest conservatieve crawlers gerust.

Conversie aan de bouwzijde of direct?

Gebouwd voor bekende marketingmiddelen (CI + Sharp). On-the-fly asynchrone conversie voor CMS-uploads – met agressieve caching als resultaat. Blokkeer nooit een gebruikersverzoek bij langzame AVIF-codering.

Het format moderniseren zonder terugval betekent het accepteren van grijze vierkanten waar zaken er nog steeds toe doen.