Anteckningar från teamet om hantverk, format och de små beslut som ligger bakom ett bra resultat.
Hur WebP når mindre storlek än PNG
WebP använder två skilda komprimeringslägen. Det förlustfria läget förenar rumslig och färgmässig förutsägelse med ett entropikodningssteg som är mer avancerat än PNG:s DEFLATE, och når enligt Googles publicerade riktmärke omkring 26 procent bättre komprimering på typiska bilder. Det lossy läget tillämpar en blockbaserad transform i stil med videokomprimering, byggd för att kasta information som ögat knappt märker och behålla det som faktiskt syns. För bilder med alfakanal använder WebP en separat förlustfri underkomprimering för alfadatan medan RGB-datan komprimeras lossy, och därför kan lossy WebP med transparens vara ungefär tre gånger mindre än en PNG vid likvärdig synlig kvalitet. PNG:s DEFLATE kan bara förlustfritt och kan inte utnyttja den perceptuella avvägning som det lossy läget gör. Formatskillnaden förklarar gapet.
Alfakanalen i detalj
Både PNG och WebP stöder 8-bitars alfatransparens, vilket betyder att varje pixel kan bära ett opacitetsvärde från 0 (helt transparent) till 255 (helt täckande). När plattformens bildmotor kodar om en PNG till WebP läser den varje pixels RGBA-värden och skickar alfavärdena direkt in i WebP-kodaren, där de bevaras med förlustfri komprimering oberoende av hur RGB-datan kodas. Resultatet är att varje transparent pixel i PNG-filen vid alfa 0, varje halvtransparent pixel mellan 1 och 254 och varje täckande pixel vid 255 mappas till exakt samma tillstånd i WebP-filen. För en logotyp med mjuka slagskuggor eller kantutjämnad text på transparent bakgrund överlever kantmjukheten orörd. Det står i kontrast till JPG, som saknar alfafält i sin containerspecifikation och måste lägga bilden mot en bakgrundsfärg innan något kodas.
Core Web Vitals och valet av bildformat
Largest Contentful Paint mäter hur lång tid det tar för det största synliga elementet på sidan att dyka upp i visningsytan. För de flesta innehållssidor är det elementet hjältebilden, och Google använder LCP som rankningssignal i sin Core Web Vitals-bedömning. PNG-bilder är en återkommande källa till LCP-problem på grund av sin filstorlek, eftersom en fotografisk PNG i 4K-upplösning kan väga flera megabyte medan motsvarande WebP nära förlustfri vanligen är en bråkdel av det. PageSpeed Insights flaggar detta specifikt i sin granskningspunkt för nästa generations format och pekar ut PNG som formatet att ersätta. Att omvandla de PNG-filer som ligger på en sidas kritiska renderingsväg till WebP är en av de mest verkningsfulla enskilda ändringarna för att förbättra uppmätt sidprestanda. Tidslinjen för webbläsarstöd gör det säkert, med WebP i Chrome från 2011, Firefox från 2019, Safari från 2020 och Edge sedan sin Chromium-ombyggnad.
Lossy utdata och inställningen nära förlustfri
WebP-kodning erbjuder en kvalitetsparameter från 0 till 100, där högre värden behåller mer detalj till priset av större filer. Det här verktyget kodar vid en fast inställning nära förlustfri, avstämd för att väga synlig trohet mot filstorlek över de typiska webbkategorierna foton, gränssnittsgrafik och ikoner. Vid den inställningen går utdatan inte att skilja från käll-PNG på normala skärmavstånd. Strikt sett förloras en del precision på bitnivå jämfört med en äkta förlustfri kodning, vilket betyder att en jämförelse byte för byte mellan de avkodade WebP-pixlarna och de ursprungliga PNG-pixlarna visar små numeriska skillnader. Dessa skillnader ligger under tröskeln för mänsklig syn på fotografiskt innehåll. För medicinsk bildtagning, satellitfotografi eller digital arkivbevaring, där förlustfri trohet är ett hårt krav, är rätt väg att behålla PNG-filen och använda WebP enbart som leveransexport, inte som arbetskopia.
Metadatans beteende
Kedjan som används för PNG-till-WebP-omvandling rensar bort EXIF-, IPTC- och XMP-metadata ur utdatan. Det matchar beteendet som observeras över alla tre stora webbläsarmotorer. ICC-färgprofiler hanteras ojämnt, där Chrome och Safari behåller sRGB-ICC-profiltaggen i WebP-utdatan och Firefox rensar all metadata inklusive ICC-profilen. Nettoresultatet är att den omvandlade WebP-filen är sRGB-säker över webbläsare, men varje bredgamuttaggning som Display-P3, Adobe RGB eller ProPhoto RGB i käll-PNG överlever inte i Firefox. För färgkritiska professionella arbetsflöden spelar denna ojämnhet roll, så om slututdatan behöver färgprofiltrohet, omvandla med ett verktyg som uttryckligen skriver ICC-data, eller lägg på profiltaggen som ett efterbehandlingssteg med en särskild redigerare för bildmetadata.
När du behåller PNG och när WebP räcker
Det praktiska beslutsträdet är kort. Om bildens slutmål är en webbsida eller webbapp och visningsmiljön är vilken webbläsare som helst från 2020 och framåt, är WebP rätt exportformat. Om bilden behöver öppnas i ett designprogram som Figma, Sketch eller Affinity Designer, kontrollera WebP-stödet i just den version du använder, eftersom stödet varierar. Om bilden ska användas i ett tryckflöde är PNG eller TIFF att föredra, eftersom de flesta tryck-RIP:ar inte hanterar WebP. Om bilden ska skickas via e-post är PNG säkrare, med tanke på hur ojämna e-postklienter är med moderna format. Om bilden ska användas som en arbetsfil som redigeras och sparas om flera gånger, behåll PNG-filen som master. WebP nära förlustfri är ett utmärkt leveransformat, och PNG är det bättre formatet för arkivering och redigering. Det ideala arbetsflödet behåller PNG som original och exporterar WebP för webbleverans.