Notater fra teamet om håndverket, formater og de små valgene bak et godt resultat.
Hvordan ett bilde konverteres i nettleseren, og hva som endres for flere
Når du slipper en JPEG på siden, leser nettleseren filen inn i minnet, dekoder de komprimerte dataene tilbake til rå piksler med sin innebygde JPEG-leser, tegner pikslene på en flate utenfor skjermen og ber plattformen skrive dem ut igjen som WebP. Hvert steg skjer i nettleseren, på din egen maskinvare, så ingen byte krysser nettet. I våre kjøringer blir en JPEG på i 1024 ganger 768 ferdig på rundt 54 millisekunder, og et bilde på i 3840 ganger 2160 tar omtrent 550 millisekunder. Når du konverterer flere bilder på en gang, flyttes jobben i stedet til serveren vår, som koder dem sammen og gir tilbake én nedlasting der lenken slettes innen omtrent 2 timer.
Hva skjer med EXIF og metadata
JPEG-filer kan slepe rundt på ekte metadata-laster. EXIF registrerer kameramodellen, GPS-koordinater, lukkerhastighet og orientering. IPTC-felt holder opphavsrett og bildetekst. XMP-pakker sporer redigeringshistorikk, og ICC-profiler dekker fargestyrt arbeid. Konverteringen her beholder ingen av det. WebP-utgangen er en ren fil som holder bare de synlige pikslene. Det er den normale oppførselen for bildeverktøy som tegner gjennom nettleseren, på tvers av Chromium, Firefox og WebKit. For det meste av nettpublisering er det å droppe metadataen et pluss: det trimmer noen få byte og hindrer GPS eller personlige data fra å lekke inn i et offentlig bilde. Hvis du trenger ett bestemt felt beholdt, orientering er den vanlige, roter fotoet først eller bruk en metadata-bevisst redigerer før konvertering. Ikke len deg på dette verktøyet for arkivarbeid der den opprinnelige metadataen må overleve intakt.
WebP mot JPEG: hvordan komprimeringen skiller seg
JPEG deler et bilde i blokker på 8 ganger 8 og kjører en diskret cosinustransform for å gjøre romlig detalj om til frekvensdata, og kvantiserer så de høyere frekvensene hardere. WebP låner et prediksjonsopplegg fra VP8-video: hver blokk gjettes fra sine allerede avkodede naboer, og bare den gjenværende forskjellen blir lagret. Det har en tendens til å etterlate færre blokkete artefakter ved samme filstørrelse, særlig over jevne gradienter og hudtoner der JPEG-rutenettet kan dukke opp som en synlig mosaikk. På fotos ved høy kvalitet, over q80, fanger øyet sjelden forskjellen, men størrelsesfordelen holder stødig. Ved lavere kvalitet, under q60, vider WebP-ledelsen seg ut og artefaktkarakteren skifter: WebP smører ut i en mykere uskarphet mens JPEG viser sine kjennetegnende blokker. Ingen vinner på hvert bilde. Tungt teksturerte motiver som løvverk komprimerer av og til omtrent likt i begge formater.
Core Web Vitals og argumentet for WebP
Largest Contentful Paint, eller LCP, måler hvor raskt det største synlige elementet er ferdig med å laste i visningsporten. På de fleste markedsføringssider er det elementet et toppbilde. Google har bekreftet at Core Web Vitals fungerer som en rangeringsfaktor i Søk. Når toppbildet er en JPEG på, kan det skyve LCP forbi terskelen på 2,5 sekunder på en mellomklasse mobilforbindelse. Konverter det samme fotoet til WebP på rundt, og LCP kan gli tilbake inn i den grønne sonen uten noen annen endring på siden. Besparelsen på 25 til 34 prosent vokser på tvers av hvert bilde på siden. En side som bærer seks JPEG-er som til sammen utgjør kan kvitte seg med 300 til ved å bytte til WebP, noe som direkte gjør den første meningsfulle malingen raskere på trege forbindelser. CDN-er som støtter innholdsforhandling gir WebP til kompatible nettlesere på egen hånd, så det finnes ingen oppgave per bilde når originalene først finnes.
Nettleserstøtte for WebP i 2026 og hullene
Fra 2026 leses WebP i Chrome siden versjon 17, Firefox siden 65, Edge siden 18, Opera siden 11.10, og Safari siden versjon 14 på iOS 14 og macOS Big Sur. Ifølge caniuse.com topper samlet global dekning for WebP-avkoding 97 prosent av nettlesertrafikken. Den gjenværende fliken er for det meste Internet Explorer 11, Safari 13 på macOS Catalina, og en lang hale av veldig gamle Android-nettlesere. For de fleste offentlige prosjekter er det trygt å servere WebP til alle. Når du trenger total dekning, lar HTML picture-elementet deg liste en WebP-kilde og en JPEG-tilbakefall i én tagg, og nettleseren tar det første formatet den kan lese. CDN-er med bildeoptimalisering forhandler formatet automatisk fra Accept-headeren nettleseren sender, så ingen manuell testing per nettleser trengs når du serverer gjennom dem.
Når du ikke bør bruke WebP
WebP er det rette valget for nettlevering til moderne nettlesere, men det er feil valg på noen vanlige steder. Utskriftsarbeid trenger CMYK-farge, som WebP ikke bærer, så JPEG og TIFF forblir standard for trykkeriet. E-postklienter er ujevne: Gmail og Apple Mail gjengir WebP, men Outlook på Windows gjør ikke det. Fildeling og markedsplasser varierer også. Google Disk, Dropbox og GitHub viser WebP fint, mens mange sosiale plattformer, bildebyråer og e-handelssystemer omkomprimerer innkommende bilder til JPEG internt, noe som gjør WebP-steget poengløst. Redigererstøtte er fortsatt flekkete: Lightroom, Capture One og Affinity Photo kan åpne WebP, men mange plugins og eksportforhåndsinnstillinger faller fortsatt tilbake på JPEG. For enhver arbeidsflyt som sender bilder gjennom tredjepartssystemer du ikke styrer, behold en JPEG-master og konverter til WebP bare på det siste leveringslaget.
