Vad förlustfri WebP faktiskt sparar jämfört med PNG

Den korta versionen

Förlustfri WebP är ofta mindre än PNG för samma pixlar. Det är den praktiska anledningen till att människor använder det.

Men ordet "ofta" är viktigt. Förlustfri WebP är inte en magisk ersättare för varje PNG. Det tenderar att spara mest på bilder med transparens, skärmbilder, UI-fångster och blandat grafik-/fotoinnehåll. Det kan spara lite, eller ibland förlora, på mycket små resurser, kraftigt optimerade palett-PNG:er och enkla ikoner.

Om du optimerar en riktig webbplats är rätt fråga inte "Är WebP bättre än PNG?" Den är: "Vilka av mina PNG-filer blir meningsfullt mindre som förlustfri WebP, utan att skapa kompatibilitets- eller arbetsflödesproblem?"

Det är en smalare fråga, och mycket lättare att besvara.

Vad "förlustfri" betyder här

Förlustfri betyder att de avkodade pixlarna matchar källpixlarna exakt. Om en PNG konverteras till förlustfri WebP och avkodas igen ska bildpixlarna vara identiska.

Det betyder inte att filen är densamma. Metadata, hantering av färgprofiler, extra PNG-chunks, gammainformation, tidsstämplar och verktygsspecifika chunks kan ändras, tas bort eller representeras annorlunda beroende på din konverteringskedja.

Den här skillnaden är viktig om du arbetar med arkivbilder, tryckflöden, vetenskapliga bilder, juridisk bevisning eller någon situation där filbehållaren innehåller viktig information som inte är pixlar. För vanlig webbpublicering bryr sig de flesta team främst om visuella pixlar, transparens, dimensioner och färgkonsekvens.

Om du publicerar bilder som användare har laddat upp är metadata också en integritetsfråga. Vi behandlade det bredare ämnet i hur du tar bort EXIF-metadata innan du delar foton online, men samma princip gäller här: bildoptimering bör vara tydlig med vad den bevarar och vad den tar bort.

Varför PNG komprimerar bra, och var det tar stopp

PNG är ett mycket bra format. Det blev en webbstandard av goda skäl:

• Det är förlustfritt.
• Det stöder alfatransparens.
• Det har brett stöd.
• Det är förutsägbart och enkelt att arbeta med.
• Det är utmärkt för platt grafik, skärmbilder, logotyper och UI-resurser.

PNG-komprimering fungerar genom att filtrera bildrader och sedan använda DEFLATE-komprimering. Den kombinationen är effektiv, särskilt när närliggande pixlar liknar varandra.

Problemet är inte att PNG är dåligt. Problemet är att PNG är gammalt. Dess komprimeringsmodell har färre knep tillgängliga än nyare format. När du väl har optimerat en PNG med en bra kodare kan du fortfarande lämna byte på bordet eftersom formatet i sig inte kan representera vissa mönster lika effektivt som förlustfri WebP kan.

Det är där förlustfri WebP kommer in.

Vad förlustfri WebP gör annorlunda

Förlustfri WebP använder ett komprimeringssystem som är utformat specifikt för bilder, snarare än ett generellt komprimeringslager som har lagts ovanpå filtrerade rader. Under huven kan det använda tekniker som prediktiv kodning, färgtransformer, paletter, bakåtreferenser och entropikodning för att representera upprepande eller förutsägbara pixelmönster kompakt.

Du behöver inte memorera implementeringsdetaljerna. Den användbara mentala modellen är denna:

PNG komprimerar rader väl. Förlustfri WebP har fler sätt att beskriva bildstruktur.

Den extra flexibiliteten är skälet till att förlustfri WebP ofta kan skapa mindre filer från samma källbild.

Google har historiskt beskrivit förlustfria WebP-bilder som omkring 26 % mindre än PNG i genomsnitt i sina egna studier. Se det som ett riktmärke för riktningen, inte som ett löfte. Dina bilder är inte ett genomsnitt. Ditt designsystem, dina skärmbilder, produktfoton, illustrationer, exporterade resurser och CMS-uppladdningar kommer att bete sig på sitt eget sätt.

Där förlustfri WebP brukar spara mest

Transparenta bilder

PNG används ofta på grund av alfatransparens. Förlustfri WebP stöder också alfa och komprimerar det ofta effektivt.

Det är användbart för:

• Frilagda produktbilder
• Stickers och märken
• Gränssnittsöverlägg
• Diagram med transparent bakgrund
• Logotyper som exporterats större än nödvändigt

Besparingarna kan märkas när alfakanalen innehåller stora förutsägbara områden, mjuka kanter eller upprepade former. Om du har en katalog full av transparenta produktbilder är förlustfri WebP värt att testa tidigt.

Skärmbilder och UI-fångster

Skärmbilder innehåller ofta stora plana ytor, upprepade gränssnittskomponenter, text, ikoner, skuggor och vissa fotografiska områden. Den blandningen kan vara besvärlig för PNG, särskilt vid stora dimensioner.

Förlustfri WebP hanterar ofta dessa bilder väl. En helsides skärmbild av ett UI som är 900 KB som optimerad PNG kan bli 500–700 KB som förlustfri WebP. Ibland är besparingen större. Ibland är den mindre. Men kategorin är lovande.

Om dessa skärmbilder visas i dokumentation, marknadsföringssidor, onboarding-flöden eller fallstudier kan den samlade effekten vara verklig.

Blandat illustrations- och bildinnehåll

Många moderna webbgrafiker är varken rena illustrationer eller rena foton. Tänk på en hero-bild som innehåller produkt-UI, gradienter, små ikoner, textetiketter och inbäddade foton.

PNG kan bevara den perfekt men skapa en stor fil. Förstörande WebP eller AVIF kan skapa artefakter runt text och kanter om de pressas för hårt. Förlustfri WebP kan vara en rimlig medelväg när exakta kanter spelar roll.

För ett bredare beslutsträd över bildformat, inklusive AVIF och förstörande WebP, se Bildformat 2026: när AVIF slår WebP och när det inte gör det.

Där PNG fortfarande kan vara bättre

Små ikoner och enkla resurser

För mycket små filer spelar formatets overhead roll. En PNG-ikon på 650 byte är inte en självklar kandidat för konvertering. WebP kanske sparar 80 byte, eller så blir den större.

I den skalan kan den operativa komplexiteten väga tyngre än nyttan. Om filen redan är minimal, inte renderingsblockerande och cachas under lång tid har du förmodligen bättre saker att åtgärda.

Noggrant optimerade palett-PNG:er

Vissa PNG-filer är mycket mindre än man kan tro eftersom de använder en begränsad palett. En bra PNG med indexerade färger kan vara svår att slå för enkel grafik.

Det gäller särskilt för:

• Små logotyper
• Pixelkonst
• Platta ikoner
• Enkla diagram
• Grafik med få färger

Var försiktig när du jämför WebP med slarviga PNG-exporter. Om PNG-filen kom direkt från ett designverktyg med onödiga metadata och dåliga komprimeringsinställningar kan WebP se dramatiskt bättre ut. Det betyder inte att WebP slog en väloptimerad PNG med samma marginal.

Ett rättvist test jämför förlustfri WebP med optimerad PNG, inte med vilken fil som råkade laddas upp.

Bilder som borde vara förstörande i stället

Det här är det tysta misstaget: team konverterar PNG till förlustfri WebP när bilden inte borde ha varit PNG från början.

Fotografier är det vanliga fallet. Ett fullfärgsfoto sparat som PNG kan vara enormt. Att konvertera det till förlustfri WebP kan minska filen, men den kommer vanligtvis fortfarande att vara mycket större än en högkvalitativ förstörande WebP eller AVIF.

Om användaren inte kan uppfatta skillnaden är förlustfrihet ofta fel mål. Produktfotografi, redaktionella bilder, bakgrunder och porträtt hör vanligtvis hemma i ett förstörande format med rimliga kvalitetsinställningar.

Förlustfritt bör reserveras för fall där exakta pixlar spelar roll: UI-skärmbilder, diagram, texttung grafik, transparens, genererade diagram och resurser som försämras synligt under förstörande komprimering.

Vad det sparar utöver byte

Den uppenbara besparingen är överföringsstorlek. Mindre bildfiler betyder vanligtvis mindre bandbredd, snabbare nedladdningar och bättre beteende på långsamma anslutningar.

Men det finns sekundära fördelar:

• Mindre data används av besökare med trafikbegränsade abonnemang
• Snabbare fyllning av bildcache
• Minskad CDN-bandbredd
• Lägre lagrings- och backupvolym i stor skala
• Mindre press på prestandabudgetar

Dessa besparingar är inte jämnt fördelade. En enda PNG på 2 MB som konverteras till en WebP på 900 KB spelar större roll än femtio ikoner som minskas med 100 byte vardera.

Det är därför bildoptimering bör prioriteras efter sidpåverkan, inte efter formatideologi. Om Lighthouse flaggar bildleverans, läs det som en ledtråd, inte en dom. Vår guide om hur du läser en Lighthouse-rapport utan panik förklarar hur du skiljer meningsfulla prestandaproblem från brusiga diagnostikresultat.

Avvägningen kring avkodningskostnad

Mindre filer är inte den enda prestandavariabeln. Webbläsare behöver också avkoda bilder innan de målas upp.

PNG-avkodning är mogen och vanligtvis snabb. WebP-avkodning har också brett stöd och är effektiv, men den kan kosta mer CPU i vissa fall. På moderna enheter är detta sällan ett hinder, men på enklare telefoner, bildtunga sidor eller stora resurser ovanför sidvecket är det värt att mäta.

Den praktiska regeln: om förlustfri WebP minskar en stor PNG med 30–50 % dominerar nätverksbesparingen vanligtvis. Om den minskar en liten PNG med 3 % är avvägningen förmodligen inte värd att bry sig om.

Prestandaarbete är fullt av sådana tröskelbeslut. Optimera inte varje byte med samma intensitet.

En enkel testmetod

Använd en representativ uppsättning, inte en enda bild.

Skapa en mapp med exempel från din faktiska webbplats:

• Logotyper och ikoner
• Skärmbilder
• Frilagda produktbilder
• Diagram
• CMS-uppladdade PNG-filer
• Sociala förhandsvisningsbilder
• Stora hero-grafiker

Jämför sedan tre saker:

1. Den ursprungliga PNG-filen som laddades upp
2. En optimerad PNG
3. En förlustfri WebP-version

För kommandoradsflöden använder team ofta verktyg som oxipng, pngcrush, zopflipng eller cwebp -lossless. Det exakta verktyget spelar mindre roll än disciplinen att jämföra lika med lika.

Följ upp:

• Filstorlek
• Pixelidentitet efter avkodning
• Visuell rendering i målwebbläsare
• Korrekt transparens
• Färgåtergivning
• Byggtid
• Friktion i CMS eller designflöde

Ett enkelt kalkylblad räcker. Lägg till ursprunglig filstorlek, optimerad PNG-storlek, förlustfri WebP-storlek, procent sparat och sidan där bilden visas.

Sortera sedan efter totalt sparade byte. Den sorteringen brukar visa vad du bör göra.

Leverans: bryt inte äldre klienter i onödan

WebP-stödet är nu brett i moderna webbläsare. För de flesta publika webbplatser är det säkert att använda. Men om du har inbäddade webviews, e-postklienter, äldre företagswebbläsare, native-appar eller ovanliga crawlers i mixen, testa innan du ersätter PNG rakt av.

Det konservativa mönstret är att behålla PNG som fallback och leverera WebP där det stöds:

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

Det här tillvägagångssättet är tråkigt, och tråkigt är bra. Användare med WebP-stöd får den mindre filen. Alla andra får PNG-filen.

Om ditt byggsystem fingeravtrycksmärker resurser och ditt CDN cachar dem korrekt är detta inte svårt att underhålla. Om ditt CMS gör alternativa format besvärliga, börja med de största och mest upprepade bilderna i stället för att försöka konvertera hela mediebiblioteket i en enda sprint.

Integritet och lokal bearbetning

Bildkonvertering sker ofta i byggkedjor eller serverbaserade medietjänster. Det är bra för många team. Men om du hanterar känsliga skärmbilder, kunduppladdningar eller interna dokument bör du vara medveten om var filer bearbetas.

Bildverktyg i webbläsaren har blivit tillräckligt bra för många enkla konverteringar, förhandsvisningar och metadatakontroller. Det finns begränsningar, men lokal bearbetning kan minska onödiga uppladdningar av privata bilder. Vi behandlade avvägningarna i varför bildbearbetning i webbläsaren är en integritetsvinst.

För interna resurser är huvudpoängen tydlig policy. Vet om bilder lämnar enheten, var transformerade versioner lagras och om metadata bevaras.

En praktisk tumregel

Använd förlustfri WebP när alla tre stämmer:

• Källan är för närvarande PNG.
• Exakta pixlar eller ren transparens spelar roll.
• Förlustfri WebP sparar en meningsfull mängd efter jämförelse med en optimerad PNG.

Behåll PNG när:

• Filen är mycket liten.
• PNG-filen redan är palettoptimerad och konkurrenskraftig.
• Kompatibilitetskraven är ovanliga.
• Den operativa komplexiteten inte är värd de sparade byten.

Använd förstörande WebP eller AVIF när:

• Bilden är fotografisk.
• Exakta pixlar inte spelar roll.
• En kvalitetsinställning kan minska storleken dramatiskt utan synlig skada.

Den bästa bildstrategin är sällan ett format överallt. Det är en liten uppsättning regler som tillämpas konsekvent.

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

💡 Prova detta: Kör samma PNG genom Image Converter för att skapa en förlustfri WebP-version och jämför filstorlekarna direkt.

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

Så, vad sparar förlustfri WebP faktiskt?

Det sparar byte där PNG har fått slut på komprimeringsknep. Ibland innebär det blygsamma 10 %. Ibland innebär det att en stor transparent bild nästan halveras. På en riktig webbplats är besparingarna vanligtvis koncentrerade till en minoritet av resurserna.

Det är den viktiga delen. Förlustfri WebP är inte en moralisk uppgradering från PNG. Det är ett praktiskt alternativ för ett specifikt jobb: mindre förlustfria webbilder med transparens och brett stöd i moderna webbläsare.

Använd det där siffrorna motiverar det. Låt PNG vara i fred där de inte gör det.