Anteckningar från teamet om hantverk, format och de små beslut som ligger bakom ett bra resultat.
Hur en enda bild görs om i webbläsaren, och vad som ändras för flera
När du släpper en JPEG på sidan läser webbläsaren in filen i minnet, avkodar den komprimerade datan tillbaka till råa pixlar med sin inbyggda JPEG-läsare, ritar pixlarna på en yta utanför skärmen och ber plattformen skriva ut dem som WebP. Varje steg sker i webbläsaren, på din egen hårdvara, så ingen byte korsar nätet. I våra körningar blir en JPEG på i 1024 gånger 768 klar på ungefär 54 millisekunder, och ett foto på i 3840 gånger 2160 tar omkring 550 millisekunder. När du gör om flera bilder på en gång flyttas jobbet i stället till vår server, som kodar dem tillsammans och lämnar tillbaka en enda nedladdning vars länk raderas inom ungefär 2 timmar.
Vad som händer med EXIF och metadata
JPEG-filer kan släpa på riktiga metadatalaster. EXIF noterar kameramodell, GPS-koordinater, slutartid och orientering. IPTC-fält håller upphovsrätt och bildtext. XMP-paket spårar redigeringshistorik, och ICC-profiler täcker färghanterat arbete. Omvandlingen här behåller inget av det. Den färdiga WebP är en ren fil med bara de synliga pixlarna. Det är det normala beteendet för bildverktyg som ritar genom webbläsaren, över Chromium, Firefox och WebKit lika. För det mesta webbpublicerandet är det ett plus att släppa metadata: det trimmar några byte och hindrar GPS eller personliga data från att läcka in i en offentlig bild. Behöver du ett visst fält bevarat, vanligen orientering, rotera fotot först eller använd en metadatamedveten redigerare före omvandlingen. Luta dig inte mot det här verktyget för arkivarbete där originalmetadata måste överleva intakt.
WebP mot JPEG: hur komprimeringen skiljer sig
JPEG delar en bild i block på 8 gånger 8 och kör en diskret cosinustransform för att göra rumsligt detalj till frekvensdata, och kvantiserar sedan de högre frekvenserna hårdare. WebP lånar ett förutsägelseschema från VP8-video: varje block gissas från sina redan avkodade grannar, och bara den kvarvarande skillnaden lagras. Det lämnar oftast färre blockiga artefakter vid samma filstorlek, framför allt över mjuka övergångar och hudtoner där JPEGs rutnät kan dyka upp som en synlig mosaik. På foton vid hög kvalitet, över q80, fångar ögat sällan skillnaden, men storleksfördelen håller stadigt. Vid lägre kvalitet, under q60, vidgas WebPs försprång och artefakternas karaktär skiftar: WebP smetar ut i en mjukare oskärpa medan JPEG visar sina kännetecknande block. Inget vinner på varje bild. Tungt texturerade motiv som lövverk komprimerar ibland ungefär lika i båda formaten.
Core Web Vitals och argumentet för WebP
Largest Contentful Paint, eller LCP, mäter hur snabbt det största synliga elementet i vyn är klart att laddas. På de flesta marknadsföringssidor är det elementet ett toppfoto. Google har bekräftat att Core Web Vitals fungerar som en rankningsfaktor i söket. När toppbilden är en JPEG på kan den knuffa LCP förbi tröskeln på 2,5 sekunder på en medelmåttig mobiluppkoppling. Gör om samma foto till WebP på runt och LCP kan glida tillbaka in i den gröna zonen utan annan ändring på sidan. Vinsten på 25 till 34 procent byggs på över varje bild på sidan. En sida med sex JPEG på sammanlagt kan tappa 300 till genom att byta till WebP, vilket direkt snabbar upp den första meningsfulla ritningen på långsamma länkar. CDN som stöder innehållsförhandling ger kompatibla webbläsare WebP på egen hand, så det finns inget pyssel per bild när originalen väl finns.
WebP-stöd 2026 och luckorna
Från och med 2026 läser WebP i Chrome sedan version 17, Firefox sedan 65, Edge sedan 18, Opera sedan 11.10 och Safari sedan version 14 på iOS 14 och macOS Big Sur. Enligt caniuse.com toppar den samlade globala täckningen för WebP-avkodning 97 procent av webbläsartrafiken. Det som återstår är mest Internet Explorer 11, Safari 13 på macOS Catalina och en lång svans av mycket gamla Android-webbläsare. För nästan varje offentligt projekt är det säkert att servera WebP till alla. När du behöver full täckning låter HTML-picture-elementet dig lista en WebP-källa och en JPEG-reserv i en tagg, och webbläsaren tar det första formatet den kan läsa. CDN med bildoptimering förhandlar formatet automatiskt utifrån Accept-huvudet webbläsaren skickar, så att servera genom dem kräver inget manuellt test per webbläsare.
När WebP är fel val
För modern webbleverans är WebP rätt, men fel på ett par vanliga ställen. Tryckarbete behöver CMYK-färg, som WebP inte bär, så JPEG och TIFF förblir standard för pressen. E-postklienter är ojämna: Gmail och Apple Mail visar WebP, men Outlook på Windows gör det inte. Fildelning och marknadsplatser varierar också. Google Drive, Dropbox och GitHub visar WebP fint, medan många sociala plattformar, bildbyråer och e-handelssystem pressar tillbaka inkommande bilder till JPEG internt, vilket gör WebP-steget meningslöst. Redigerarstödet är fortfarande ojämnt: Lightroom, Capture One och Affinity Photo kan öppna WebP, men gott om insticksprogram och exportförval väljer fortfarande JPEG som standard. För varje arbetsflöde som skickar bilder genom tredjepartssystem du inte styr, behåll en JPEG-master och gör om till WebP först i det sista leveranslagret.