Noter fra teamet om håndværk, formater og de små beslutninger bag et godt resultat.
Hvordan ét billede konverteres i browseren, og hvad der ændrer sig for flere
Når du slipper en JPEG på siden, læser browseren filen ind i hukommelsen, afkoder de komprimerede data tilbage til rå pixels med sin indbyggede JPEG-læser, tegner de pixels på en flade uden for skærmen og beder platformen skrive dem ud igen som WebP. Hvert trin sker i browseren, på din egen hardware, så ingen byte krydser nettet. I vores kørsler bliver en JPEG på i 1024 gange 768 færdig på omkring 54 millisekunder, og et billede på i 3840 gange 2160 tager cirka 550 millisekunder. Når du konverterer flere billeder på én gang, flytter arbejdet i stedet til vores server, som koder dem sammen og giver ét download tilbage, hvis link slettes inden for cirka 2 timer.
Hvad der sker med EXIF og metadata
JPEG-filer kan slæbe rundt på rigtige metadata-laster. EXIF registrerer kameramodellen, GPS-koordinater, lukkertid og orientering. IPTC-felter holder ophavsret og billedtekst. XMP-pakker sporer redigeringshistorik, og ICC-profiler dækker farvestyret arbejde. Konverteringen her beholder intet af det. WebP-outputtet er en ren fil, der kun holder de synlige pixels. Det er den normale opførsel for billedværktøjer, der tegner gennem browseren, på tværs af Chromium, Firefox og WebKit. For det meste webudgivelse er det et plus at smide metadataen væk: det trimmer et par byte og stopper GPS eller persondata fra at sive ind i et offentligt billede. Hvis du har brug for ét bestemt felt bevaret, orientering er det sædvanlige, så rotér fotoet først eller brug en metadata-bevidst redigerer før konvertering. Læn dig ikke op ad dette værktøj til arkivarbejde, hvor de oprindelige metadata skal overleve intakt.
WebP mod JPEG: hvordan komprimeringen adskiller sig
JPEG skærer et billede i blokke på 8 gange 8 og kører en diskret cosinustransformation for at gøre rumlig detalje om til frekvensdata, og kvantiserer så de højere frekvenser hårdere. WebP låner et forudsigelsesskema fra VP8-video: hver blok gættes ud fra sine allerede afkodede naboer, og kun den tilbageværende forskel gemmes. Det har en tendens til at efterlade færre blokkede artefakter ved den samme filstørrelse, især over jævne gradienter og hudtoner, hvor JPEG-gitteret kan dukke op som en synlig mosaik. På fotos ved høj kvalitet, over q80, fanger øjet sjældent forskellen, men størrelsesfordelen holder støt. Ved lavere kvalitet, under q60, vider WebP-forspringet sig ud, og artefaktkarakteren skifter: WebP smører ud i en blødere sløring, mens JPEG viser sine kendetegnende blokke. Ingen vinder på hvert billede. Tungt teksturerede motiver som løv komprimerer nogle gange omtrent ens i begge formater.
Core Web Vitals og argumentet for WebP
Largest Contentful Paint, eller LCP, måler, hvor hurtigt det største synlige element bliver færdigt med at indlæse i visningsfeltet. På de fleste marketingsider er det element et toptbillede. Google har bekræftet, at Core Web Vitals fungerer som en rangeringsfaktor i Søgning. Når toptbilledet er et JPEG på, kan det skubbe LCP forbi tærsklen på 2,5 sekunder på en mellemklasse mobilforbindelse. Konverter det samme foto til WebP på omkring, og LCP kan glide tilbage ind i den grønne zone uden nogen anden ændring på siden. Besparelsen på 25 til 34 procent vokser på tværs af hvert billede på siden. En side, der bærer seks JPEG-er, som tilsammen udgør, kan smide 300 til ved at skifte til WebP, hvilket direkte gør den første meningsfulde optegning hurtigere på langsomme forbindelser. CDN-er, der understøtter indholdsforhandling, giver WebP til kompatible browsere af sig selv, så der er ingen opgave per billede, når originalerne først findes.
Browserunderstøttelse af WebP i 2026 og hullerne
Fra 2026 læses WebP i Chrome siden version 17, Firefox siden 65, Edge siden 18, Opera siden 11.10, og Safari siden version 14 på iOS 14 og macOS Big Sur. Ifølge caniuse.com topper den samlede globale dækning for WebP-afkodning 97 procent af browsertrafikken. Den tilbageværende stump er for det meste Internet Explorer 11, Safari 13 på macOS Catalina, og en lang hale af meget gamle Android-browsere. For de fleste offentlige projekter er det sikkert at servere WebP til alle. Når du har brug for total dækning, lader HTML picture-elementet dig liste en WebP-kilde og en JPEG-tilbagefald i ét tag, og browseren tager det første format, den kan læse. CDN-er med billedoptimering forhandler formatet automatisk ud fra den Accept-header, browseren sender, så ingen manuel test per browser er nødvendig, når du serverer gennem dem.
Hvornår du ikke bør bruge WebP
WebP er det rigtige valg til weblevering til moderne browsere, men det er det forkerte valg på et par almindelige steder. Trykarbejde har brug for CMYK-farve, som WebP ikke bærer, så JPEG og TIFF forbliver standard for pressen. E-mailklienter er ujævne: Gmail og Apple Mail gengiver WebP, men Outlook på Windows gør ikke. Fildeling og markedspladser varierer også. Google Drev, Dropbox og GitHub viser WebP fint, mens mange sociale platforme, billedbureauer og e-handelssystemer komprimerer indkommende billeder til JPEG internt, hvilket gør WebP-trinnet meningsløst. Redigerer-understøttelse er stadig plettet: Lightroom, Capture One og Affinity Photo kan åbne WebP, men masser af plugins og eksport-forindstillinger falder stadig tilbage på JPEG. For enhver arbejdsgang, der sender billeder gennem tredjepartssystemer, du ikke styrer, så behold en JPEG-master og konverter til WebP kun på det sidste leveringslag.