Oppsummering
Den gratis bildekomprimereren koder JPEG-, PNG- og WebP-filene dine på nytt i nettleseren, prøver det lettere formatet for hver av dem (WebP når det vinner) og beholder den minste filen. Ingenting lastes opp. Start med standardkvaliteten på 80%, sammenlign resultatet i full størrelse, og endre deretter størrelsen på bildene til bredden de vises i før du publiserer, fordi verktøyet beholder de opprinnelige dimensjonene.
Vil du vite mer? Spør
En bildekomprimerer gjør den tyngste delen av de fleste sider lettere. På en median forside veier bilder 1 054 KB på desktop og 900 KB på mobil, av en total sidevekt på 2 652 KB og 2 311 KB (HTTP Archive, Web Almanac 2024, sidevekt). Googles egne retningslinjer for bilder sier det samme: bilder er «ofte den største bidragsyteren til total sidestørrelse», noe som gjør sider trege og dyre å laste (Google Search Central, beste praksis for SEO med bilder).
Hvordan fungerer den gratis bildekomprimereren?
Dra ett eller flere bilder inn i verktøyet, velg kvaliteten, og last ned de lettere filene. Alt skjer på enheten din: nettleseren leser hver fil, tegner den på nytt og koder den på nytt, så bildene dine sendes aldri til en server.
- Legg til filene: JPEG, PNG eller WebP, opptil 10 MB hver. Du kan velge flere om gangen.
- Velg kvaliteten med glidebryteren, fra 10% (maksimal komprimering) til 100% (maksimal kvalitet). Standarden er 80%.
- Les rapporten: den totale besparelsen, deretter en linje per bilde med endelig størrelse, dimensjoner og utdataformat.
- Last ned hver fil, eller alle samtidig med ett klikk. Hvert navn starter med «compressed-», slik at du aldri overskriver et original ved en feiltakelse.
Flytt glidebryteren etter en første kjøring, så komprimerer verktøyet de samme filene på nytt. Det gjør det raskt å sammenligne to innstillinger.
Hvilket format velger verktøyet for hvert bilde?
Det tester kandidatene og beholder den minste filen. Hvis ingen kandidat slår originalen, beholder det originalen og sier at bildet allerede er optimalisert.
| Du laster opp | Formater som testes | Det du vanligvis får |
|---|---|---|
| JPEG-bilde | JPEG og WebP med din kvalitetsinnstilling | WebP i de fleste tilfeller, JPEG når den er mindre |
| PNG (logo, skjermbilde, gjennomsiktighet) | WebP med din kvalitetsinnstilling og PNG kodet på nytt | WebP, som beholder gjennomsiktigheten |
| WebP | WebP med din kvalitetsinnstilling | En lettere WebP, eller originalen hvis den allerede var lett |
WebP vinner ofte av en dokumentert grunn: Google måler at WebP-filer uten tap er 26% mindre enn PNG-filer, og at WebP-filer med tap er 25 til 34% mindre enn sammenlignbare JPEG-filer ved tilsvarende kvalitet, med gjennomsiktighet støttet i begge modusene (Google for Developers, WebP). Google Search indekserer bilder i BMP, GIF, JPEG, PNG, WebP, SVG og AVIF, så en WebP-fil er trygg også for bildesøk.
Hvilken kvalitetsinnstilling bør du bruke?
Bruk 80% for bilder, og gå lavere først etter at du har sjekket resultatet i full størrelse. Glidebryteren sender en kvalitetsverdi mellom 0 og 1 til nettleserens koder, den vanlige måten nettlesere eksporterer bilder med tap (MDN, HTMLCanvasElement.toBlob()). Lavere verdier fjerner mer detalj; riktig nivå avhenger av hva bildet viser.
| Kvalitet | Best for | Det du bør sjekke |
|---|---|---|
| 90 til 100% | Nærbilder av produkter, porteføljearbeid, bilder brukere zoomer inn i | Besparelsen kan være liten; behold originalen hvis gevinsten er marginal |
| 75 til 85% | De fleste bilder: bloggomslag, hovedbilder, teambilder | Ansikter og hudtoner i full størrelse |
| 60 til 70% | Bakgrunnsbilder, miniatyrbilder, dekorative bilder | Striper i himmel og gradienter |
| Under 60% | Bare veldig små forhåndsvisninger | Uskarphet og blokkete kanter rundt tekst eller logoer |
Skjermbilder og bilder med tekst fortjener en høyere innstilling enn fotografier: komprimeringsfeil viser seg først rundt skarpe bokstaver.
Hvorfor betyr bildevekten noe for SEO?
Fordi hovedbildet på en side ofte er det Google måler. Largest Contentful Paint (LCP) måler når det største synlige elementet vises, og en god score er 2,5 sekunder eller mindre på 75. persentil av sidelastinger (web.dev, Largest Contentful Paint). På mobil er et bilde LCP-elementet på 68% av sidene (Web Almanac 2024, Media).
Google anbefaler gode Core Web Vitals «for suksess med Search», og sier at de samsvarer med det kjernerangeringssystemene deres ønsker å belønne (Google, Core Web Vitals og Search). Et lettere hovedbilde er en av de mest direkte måtene å forbedre LCP-en din på.
Komprimering er likevel ikke hele historien. Googles LCP-veiledning forklarer at en mindre fil forkorter nedlastingen, men hvis nettleseren oppdager eller viser bildet sent, flyttes tiden som spares bare til et annet steg (web.dev, Optimize LCP). Komprimer filen, og sørg deretter for at hovedbildet står i HTML-en fra start og ikke er lat-lastet.
Hvordan forbereder du bilder før du komprimerer dem?
Endre størrelse først, og komprimer deretter. Komprimereren beholder pikseldimensjonene i filen din, så et fotografi på 4 000 piksler som vises med 800 piksler, har fortsatt 25 ganger flere piksler enn skjermen viser.
- Endre størrelsen til visningsstørrelsen: omtrent dobbelt så bred som bildet vises, er nok for skarpe skjermer. Et fullbredde bloggomslag trenger sjelden mer enn 1 600 til 2 000 piksler.
- Beskjær det som ikke hjelper: tomme marger koster byte og oppmerksomhet.
- Komprimer på 80%, sammenlign, juster.
- Gi filen nytt navn med noen beskrivende ord, for eksempel «rode-terrengloepesko.webp», siden Google sier at et kort og beskrivende filnavn gir lette hint om hva bildet handler om.
- Skriv alt-teksten når du setter bildet inn: se ordlisteoppføringen vår om alt-tekst.
Ved å kode på nytt i nettleseren fjernes også kameraets metadata som ligger lagret i originalfilen, noe som sparer noen kilobyte ekstra på bilder tatt med mobil eller kamera.
Hvor tung bør et bilde være?
Det finnes ingen offisiell grense, men praktiske budsjetter holder sidene raske. Bruk disse målene som utgangspunkt, og mål hele siden med sjekken av sidestørrelse.
- Hovedbilde eller omslagsbilde: under 150 til 200 KB, siden det ofte avgjør LCP.
- Bilder i en artikkel: under 100 KB hver.
- Miniatyrbilder og logoer: noen titalls KB på det meste.
- Hele siden: sammenlign med medianen ovenfor. Mobile undersider har i medianen 348 KB med bilder, noe som viser hvor mye lettere en godt bygd artikkel kan være.
Hvilke feil opphever gevinsten av komprimering?
De fleste skjer etter komprimeringssteget, når bildet plasseres på siden.
- Lat-lasting av hovedbildet. Nesten en av ti LCP-bilder på mobil er lat-lastet, et antimønster som gjør sider mye tregere (Web Almanac 2024, Media). Behold
loading="lazy"for bilder under det synlige området. - Ingen bredde- og høydeattributter. Uten dem hopper siden når bildet kommer, noe som svekker layoutstabiliteten.
- En stor fil for alle skjermer. Server mindre versjoner til telefoner med
srcset. - Å komprimere samme JPEG om og om igjen. Hver komprimering med tap mister detalj. Behold en master med høy kvalitet og komprimer fra den.
- Å glemme CMS-et. Noen plattformer lager egne versjoner av hvert opplastet bilde; sjekk filen som faktisk serveres, ikke den du lastet opp.
Hvordan holder du alle sider lette over tid?
Gjør komprimering til en del av publiseringen, og revider deretter jevnlig. Kjør SEO-revisjonen på siden på nøkkelsidene dine for å fange opp tunge bilder og manglende alt-tekst, og les veiledningen vår om bildeoptimalisering for hele sjekklisten.
Hvis du publiserer ofte, kan du automatisere rutinen. Sorank-generatoren for bloggartikler skriver og publiserer illustrerte artikler på nettstedet ditt, og GEO- og SEO-dashbordet følger Google-trafikken og AI-synligheten som disse sidene oppnår.
Endre størrelse, komprimer på 80%, sjekk i full størrelse: den rutinen fjerner det meste av vekten fra sidene dine. Dra bildene dine inn i komprimereren over, og se deretter Sorank-abonnementene for å publisere optimalisert innhold på autopilot.
