Wat WebP lossless je daadwerkelijk bespaart ten opzichte van PNG

De korte versie

WebP lossless is voor dezelfde pixels vaak kleiner dan PNG. Dat is de praktische reden waarom mensen het gebruiken.

Maar het woord "vaak" is belangrijk. WebP lossless is geen magische vervanging voor elke PNG. Het levert meestal de meeste besparing op bij afbeeldingen met transparantie, screenshots, UI-opnamen en gemengde grafische/fotografische content. Het kan weinig besparen, of soms zelfs groter uitvallen, bij zeer kleine assets, sterk geoptimaliseerde palet-PNG’s en eenvoudige iconen.

Als je een echte website optimaliseert, is de juiste vraag niet "Is WebP beter dan PNG?" Maar: "Welke van mijn PNG’s worden betekenisvol kleiner als WebP lossless, zonder compatibiliteits- of workflowproblemen te veroorzaken?"

Dat is een nauwere vraag, en veel makkelijker te beantwoorden.

Wat "lossless" hier betekent

Lossless betekent dat de gedecodeerde pixels exact overeenkomen met de bronpixels. Als een PNG wordt geconverteerd naar WebP lossless en daarna weer wordt gedecodeerd, zouden de beeldpixels identiek moeten zijn.

Het betekent niet dat het bestand hetzelfde is. Metadata, verwerking van kleurprofielen, aanvullende PNG-chunks, gamma-informatie, tijdstempels en tool-specifieke chunks kunnen worden gewijzigd, verwijderd of anders worden weergegeven, afhankelijk van je conversiepijplijn.

Dit onderscheid is belangrijk als je werkt met archiefbeelden, printworkflows, wetenschappelijke beelden, juridisch bewijs of elke situatie waarin de bestandscontainer belangrijke niet-pixelinformatie bevat. Voor gewone webdistributie geven de meeste teams vooral om visuele pixels, transparantie, afmetingen en kleurconsistentie.

Als je door gebruikers aangeleverde afbeeldingen publiceert, is metadata ook een privacykwestie. We hebben dat bredere onderwerp behandeld in EXIF-metadata verwijderen voordat je foto’s online deelt, maar hetzelfde principe geldt hier: beeldoptimalisatie moet expliciet zijn over wat behouden blijft en wat wordt verwijderd.

Waarom PNG goed comprimeert, en waar de grens ligt

PNG is een heel goed formaat. Het werd om goede redenen een webstandaard:

• Het is lossless.
• Het ondersteunt alfatransparantie.
• Het wordt breed ondersteund.
• Het is voorspelbaar en eenvoudig om mee te werken.
• Het is uitstekend voor vlakke graphics, screenshots, logo’s en UI-assets.

PNG-compressie werkt door afbeeldingsrijen te filteren en daarna DEFLATE-compressie toe te passen. Die combinatie is effectief, vooral wanneer nabijgelegen pixels op elkaar lijken.

Het probleem is niet dat PNG slecht is. Het probleem is dat PNG oud is. Het compressiemodel heeft minder trucs beschikbaar dan nieuwere formaten. Als je een PNG eenmaal hebt geoptimaliseerd met een goede encoder, kun je nog steeds bytes laten liggen omdat het formaat zelf sommige patronen niet zo efficiënt kan weergeven als WebP lossless dat kan.

Daar komt WebP lossless in beeld.

Wat WebP lossless anders doet

WebP lossless gebruikt een compressiesysteem dat specifiek is ontworpen voor afbeeldingen, in plaats van een algemene compressielaag die op gefilterde rijen is gezet. Onder de motorkap kan het technieken gebruiken zoals voorspellende codering, kleurtransformaties, paletten, terugverwijzingen en entropiecodering om herhalende of voorspelbare pixelpatronen compact weer te geven.

Je hoeft de implementatiedetails niet uit je hoofd te leren. Het nuttige mentale model is dit:

PNG comprimeert rijen goed. WebP lossless heeft meer manieren om beeldstructuur te beschrijven.

Die extra flexibiliteit is waarom WebP lossless vaak kleinere bestanden kan maken uit dezelfde bronafbeelding.

Google heeft WebP lossless-afbeeldingen historisch beschreven als gemiddeld ongeveer 26% kleiner dan PNG in eigen onderzoeken. Zie dat als een richtinggevende benchmark, niet als een belofte. Jouw afbeeldingen zijn geen gemiddelde. Je designsysteem, screenshots, productfoto’s, illustraties, geëxporteerde assets en CMS-uploads zullen hun eigen gedrag hebben.

Waar WebP lossless meestal het meest bespaart

Transparante afbeeldingen

PNG wordt vaak gebruikt vanwege alfatransparantie. WebP lossless ondersteunt ook alfa, en comprimeert die vaak efficiënt.

Dit is nuttig voor:

• Vrijstaande productafbeeldingen
• Stickers en badges
• Interface-overlays
• Diagrammen met transparante achtergronden
• Logo’s die groter zijn geëxporteerd dan nodig

De besparing kan merkbaar zijn wanneer het alfakanaal grote voorspelbare gebieden, zachte randen of herhaalde vormen bevat. Als je een catalogus vol transparante productafbeeldingen hebt, is WebP lossless het waard om vroeg te testen.

Screenshots en UI-opnamen

Screenshots bevatten vaak grote vlakke gebieden, herhaalde interfacecomponenten, tekst, iconen, schaduwen en enkele fotografische gebieden. Die mix kan lastig zijn voor PNG, vooral bij grote afmetingen.

WebP lossless gaat vaak goed om met deze afbeeldingen. Een volledige UI-screenshot die 900 KB is als geoptimaliseerde PNG, kan 500–700 KB worden als lossless WebP. Soms is de besparing groter. Soms kleiner. Maar de categorie is veelbelovend.

Als die screenshots verschijnen in documentatie, marketingpagina’s, onboardingflows of casestudy’s, kan het gezamenlijke effect echt zijn.

Gemengde illustratie- en beeldcontent

Veel moderne webgraphics zijn geen pure illustraties en ook geen pure foto’s. Denk aan een hero-afbeelding met product-UI, verlopen, kleine iconen, tekstlabels en ingesloten foto’s.

PNG kan die perfect behouden maar een groot bestand opleveren. Lossy WebP of AVIF kan artefacten rond tekst en randen veroorzaken als je te ver comprimeert. WebP lossless kan een verstandig midden zijn wanneer exacte randen belangrijk zijn.

Voor een bredere beslisboom over afbeeldingsformaten, inclusief AVIF en lossy WebP, zie Afbeeldingsformaten in 2026: wanneer AVIF WebP verslaat en wanneer niet.

Waar PNG nog steeds beter kan zijn

Kleine iconen en eenvoudige assets

Voor zeer kleine bestanden telt formaatoverhead. Een PNG-icoon van 650 byte is geen voor de hand liggende kandidaat voor conversie. WebP kan 80 byte besparen, of juist groter worden.

Op die schaal kan de operationele complexiteit zwaarder wegen dan het voordeel. Als het bestand al klein is, niet render-blocking is en lang wordt gecachet, heb je waarschijnlijk betere dingen om op te lossen.

Zorgvuldig geoptimaliseerde palet-PNG’s

Sommige PNG’s zijn veel kleiner dan mensen verwachten omdat ze een beperkt palet gebruiken. Een goede indexed-color PNG kan moeilijk te verslaan zijn voor eenvoudige graphics.

Dit geldt vooral voor:

• Kleine logo’s
• Pixel art
• Vlakke iconen
• Eenvoudige diagrammen
• Graphics met weinig kleuren

Wees voorzichtig wanneer je WebP vergelijkt met slordige PNG-exports. Als de PNG rechtstreeks uit een designtool kwam met onnodige metadata en slechte compressie-instellingen, kan WebP er spectaculair beter uitzien. Dat betekent niet dat WebP een goed geoptimaliseerde PNG met dezelfde marge verslaat.

Een eerlijke test vergelijkt WebP lossless met geoptimaliseerde PNG, niet met het bestand dat toevallig is geüpload.

Afbeeldingen die eigenlijk lossy zouden moeten zijn

Dit is de stille fout: teams converteren PNG naar WebP lossless terwijl de afbeelding in de eerste plaats geen PNG had moeten zijn.

Foto’s zijn het gebruikelijke geval. Een full-color foto die als PNG is opgeslagen, kan enorm zijn. Conversie naar WebP lossless kan het bestand verkleinen, maar meestal blijft het veel groter dan een hoogwaardige lossy WebP of AVIF.

Als de gebruiker het verschil niet kan waarnemen, is lossless vaak het verkeerde doel. Productfotografie, redactionele beelden, achtergronden en portretten horen meestal thuis in een lossy formaat met verstandige kwaliteitsinstellingen.

Lossless moet worden gereserveerd voor gevallen waarin exacte pixels ertoe doen: UI-screenshots, diagrammen, tekstzware graphics, transparantie, gegenereerde grafieken en assets die zichtbaar verslechteren door lossy compressie.

Wat het bespaart naast bytes

De voor de hand liggende besparing is overdrachtsgrootte. Kleinere afbeeldingsbestanden betekenen meestal minder bandbreedte, snellere downloads en beter gedrag op trage verbindingen.

Maar er zijn secundaire voordelen:

• Minder dataverbruik voor bezoekers met een beperkte bundel
• Snellere opbouw van de afbeeldingscache
• Minder CDN-bandbreedte
• Minder opslag- en back-upvolume op schaal
• Minder druk op performancebudgetten

Deze besparingen zijn niet gelijk verdeeld. Eén PNG van 2 MB die wordt geconverteerd naar een WebP van 900 KB is belangrijker dan vijftig iconen die elk 100 byte kleiner worden.

Daarom moet beeldoptimalisatie worden geprioriteerd op pagina-impact, niet op formaatovertuiging. Als Lighthouse beeldlevering markeert, lees dat dan als een aanwijzing, niet als een oordeel. Onze gids over een Lighthouse-rapport lezen zonder in paniek te raken legt uit hoe je betekenisvolle performanceproblemen scheidt van ruisige diagnostiek.

De afweging rond decodeerkosten

Kleinere bestanden zijn niet de enige performancevariabele. Browsers moeten afbeeldingen ook decoderen voordat ze die kunnen tekenen.

PNG-decodering is volwassen en meestal snel. WebP-decodering wordt ook breed ondersteund en is efficiënt, maar kan in sommige gevallen meer CPU kosten. Op moderne apparaten is dit zelden een blokkade, maar op low-end telefoons, beeldzware pagina’s of grote assets boven de vouw is het de moeite waard om te meten.

De praktische regel: als WebP lossless een grote PNG met 30–50% verkleint, overheerst de netwerkbesparing meestal. Als het een kleine PNG met 3% verkleint, is de afweging waarschijnlijk niet de moeite waard om je druk over te maken.

Performancewerk zit vol met dit soort drempelbeslissingen. Optimaliseer niet elke byte met dezelfde intensiteit.

Een eenvoudige testmethode

Gebruik een representatieve batch, niet één afbeelding.

Maak een map met voorbeelden van je echte site:

• Logo’s en iconen
• Screenshots
• Vrijstaande productafbeeldingen
• Diagrammen
• Via CMS geüploade PNG’s
• Social preview-afbeeldingen
• Grote hero-graphics

Vergelijk daarna drie dingen:

1. De originele PNG zoals geüpload
2. Een geoptimaliseerde PNG
3. Een WebP lossless-versie

Voor command-line workflows gebruiken teams vaak tools zoals oxipng, pngcrush, zopflipng of cwebp -lossless. De exacte tool is minder belangrijk dan de discipline om appels met appels te vergelijken.

Houd bij:

• Bestandsgrootte
• Pixelgelijkheid na decodering
• Visuele rendering in doelbrowsers
• Correctheid van transparantie
• Kleurweergave
• Buildtijd
• Frictie in CMS- of designworkflow

Een eenvoudige spreadsheet is genoeg. Voeg de oorspronkelijke bestandsgrootte, geoptimaliseerde PNG-grootte, WebP lossless-grootte, het bespaarde percentage en de pagina waarop de afbeelding verschijnt toe.

Sorteer vervolgens op totaal bespaarde bytes. Die sorteervolgorde vertelt je meestal wat je moet doen.

Levering: breek oudere clients niet achteloos

WebP-ondersteuning is inmiddels breed in moderne browsers. Voor de meeste publieke websites is het veilig om te gebruiken. Toch geldt: als je embedded webviews, email clients, legacy enterprise browsers, native apps of ongebruikelijke crawlers in de mix hebt, test dan voordat je PNG volledig vervangt.

Het conservatieve patroon is om PNG als fallback te behouden en WebP te leveren waar het wordt ondersteund:

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

Deze aanpak is saai, en saai is goed. Gebruikers met WebP-ondersteuning krijgen het kleinere bestand. Alle anderen krijgen de PNG.

Als je buildsysteem assets van fingerprints voorziet en je CDN ze goed cachet, is dit niet moeilijk te onderhouden. Als je CMS alternatieve formaten pijnlijk maakt, begin dan met de grootste en meest herhaalde afbeeldingen in plaats van te proberen de hele mediabibliotheek in één sprint te converteren.

Privacy en lokale verwerking

Afbeeldingsconversie gebeurt vaak in buildpijplijnen of server-side mediadiensten. Dat is prima voor veel teams. Maar als je gevoelige screenshots, klantuploads of interne documenten verwerkt, wees je dan bewust van waar bestanden worden verwerkt.

Browser-side tooling voor afbeeldingen is goed genoeg geworden voor veel eenvoudige conversies, previews en metadatacontroles. Er zijn grenzen, maar lokale verwerking kan onnodige upload van privéafbeeldingen verminderen. We hebben de afwegingen behandeld in waarom afbeeldingen verwerken in de browser een privacywinst is.

Voor interne assets is het belangrijkste punt beleidsduidelijkheid. Weet of afbeeldingen het apparaat verlaten, waar getransformeerde versies worden opgeslagen en of metadata behouden blijft.

Een praktische vuistregel

Gebruik WebP lossless wanneer alle drie waar zijn:

• De bron is momenteel PNG.
• Exacte pixels of nette transparantie zijn belangrijk.
• WebP lossless bespaart een betekenisvolle hoeveelheid na vergelijking met een geoptimaliseerde PNG.

Behoud PNG wanneer:

• Het bestand heel klein is.
• De PNG al palet-geoptimaliseerd en concurrerend is.
• Compatibiliteitsbeperkingen ongebruikelijk zijn.
• De operationele complexiteit de bespaarde bytes niet waard is.

Gebruik lossy WebP of AVIF wanneer:

• De afbeelding fotografisch is.
• Exacte pixels er niet toe doen.
• Een kwaliteitsinstelling de grootte drastisch kan verkleinen zonder zichtbare schade.

De beste afbeeldingsstrategie is zelden één formaat overal. Het is een kleine set regels die consequent wordt toegepast.

<!-- tool-cta:start -->

💡 Probeer dit: Haal dezelfde PNG door Image Converter om een verliesvrije WebP-versie te maken en vergelijk de bestandsgroottes direct.

<!-- tool-cta:end -->

Dus, wat bespaart WebP lossless daadwerkelijk?

Het bespaart bytes waar PNG geen compressietrucs meer over heeft. Soms betekent dat een bescheiden 10%. Soms betekent het dat een grote transparante afbeelding bijna wordt gehalveerd. Over een echte site zijn de besparingen meestal geconcentreerd in een minderheid van de assets.

Dat is het belangrijke deel. WebP lossless is geen morele upgrade van PNG. Het is een praktische optie voor een specifieke taak: kleinere lossless webafbeeldingen met transparantie en brede ondersteuning in moderne browsers.

Gebruik het waar de cijfers het rechtvaardigen. Laat PNG met rust waar dat niet zo is.