Jag tog en 5-sekunders demonstrationsvideo, exporterade den till GIF, och såg storleken: 18 MB.
Att klistra in den i ett dokument, skicka den i en grupp eller lägga den i en README gav antingen uppladdningsfel eller väntade länge på att den skulle laddas.
Varför är en "animerad bild" större än en video, och hur får man ner storleken utan att den blir full av brus?
Först förstå varför GIF är så stor
GIF-formatet från 1987 har några inbyggda begränsningar som gör att det är "fet":
- Varje bildruta är en komplett bild. Det finns ingen "endast ändringar"-komprimering mellan rutor som videosformat har – utom om det görs en optimering vid export, annars är 100 rutor 100 bilder.
- Komprimeringsalgoritmen är gammal. GIF använder bara LZW-lossless-komprimering, som är bra på "liknande färgar i rad", men klamrar sig fast vid gradienter, foton och detaljerade texturer.
- Max 256 färger per ruta. När färger inte räcker till, använder verktygen "dithering" – små fläckar för att simulera övergångar. Detta brus ser ut att vara mjukt för ögat, men är svårt att komprimera för LZW.
Så storleken på en GIF beror ungefär på: storlek × antal rutor × hur "uppdelad" varje ruta är. Alla metoder nedan försöker att påverka dessa tre faktorer.
Sex metoder sorterade efter minsta kvalitetsförlust
1. Bildrutesoptimering: Spara bara det som förändrats (fritt från förlust)
Många skärminspelningsverktyg och designprogram exporterar GIF där varje ruta är den fulla bilden. Men i en demonstrationsvideo är det ofta bara musen och ett litet område som rör sig.
Bildrutesoptimering gör så här: varje ruta sparas bara med den rektangel som skiljer sig från föregående ruta, och de oförändrade delarna görs till transparenta pixlar. När dessa bildas en sammanhängande yta kan LZW komprimera dem effektivt.
Pixlarna förblir desamma, animationen ser exakt likadan ut, men lagringen är smartare. För GIF med en statisk bakgrund och rörliga delar (skärminspelningar, UI-demos, emojier) kan detta spara en del utrymme.
2. LZW med förlust: "Tillåt lite fel" i komprimeringsalgoritmen (visuellt fri från förlust)
Detta är tanken bakom gifsicles --lossy-parameter: under kodningen tillåts det att färger har en mycket liten avvikelse, vilket gör att fler pixlar kan räknas som "samma färg" och LZW kan bli mycket mer effektiv.
Egenskapen är: ingen minskning av färgantal, ingen ändring av storlek, ingen ändring av rutor, men priset är att bilden kan få en lätt grov yta. Ju högre värde, desto mer sparas, desto tydligare blir grovet. Vid lätt användning (t.ex. --lossy=30~40) är det svårt att märka på normal avstånd.
3. Minska färgantal: 256 färger ner till 128 eller 64
Att minska paletten från 256 till 128 eller till och med 64 färger, kräver mindre information per pixel, vilket ökar komprimeringen.
För platta illustrationer, ikoner och UI-skärminspelningar där färger inte är många, är förlusten ofta obefintlig; men för foton och bilder med många gradienter kan man se tydliga färgband och fläckar.
4. Ta bort rutor: Sänk bildfrekvens
Många GIF är exporterade med 30 eller 60 fps, men GIF klarar inte höga frekvenser bra. Många scener klarar 10–15 fps.
Halvera antalet rutor minskar oftast storleken med nästan hälften. Priset är att rörelsen inte är lika mjuk – detta påverkar demonstrationsvideos mindre, men kan vara märkbart för animationer som kräver flyt.
5. Minska storlek
Storleken är proportionell mot antalet pixlar: halvera bredd och höjd, och pixlarna är bara en fjärdedel.
Skärminspelningar gjorda på Retina-skärmar har ofta en ursprunglig bredd på över 2000 pixlar, men den visas ofta på 600–800 pixlar. Exportera i storlek som faktiskt visas är ofta den stora vinsten. Priset är att det kan se suddigt ut i förstorat läge, så vara uppmärksam på läsbarhet vid små texter.
6. Byt format: GIF till video eller WebP
Om plattformen tillåter är det den mest definitiva lösningen att inte använda GIF:
- MP4 / WebM: Modern videokodning har komprimering mellan rutor, så samma innehåll är ofta bara en bråkdel av GIF-storleken. På webben kan du skapa samma effekt med
<video autoplay loop muted playsinline>. - Dynamic WebP / APNG: Stöder fler färger och bättre komprimering, och kan spelas upp i moderna webbläsare.
Priset är kompatibilitet: många chattprogram, forum, dokumentverktyg och e-postklienter erkänner bara GIF, så om du byter format kanske det inte visas alls eller inte spelas upp automatiskt.
En tabell för att se vad som gäller
| Metod | Effekt på kvalitet | Passar för | Passar inte för |
|---|---|---|---|
| Bildrutesoptimering | Ingen (pixlar oförändrade) | Alla GIF, särskilt skärminspelningar och lokala animationer | – (bör alltid göras) |
| LZW med förlust (lätt) | Oväntat liten grov yta | De flesta GIF | Pikseldesigner som är känsliga för grov yta |
| Minska färgantal | Färgband vid gradienter | Platta illustrationer, ikoner, UI | Foton, bilder med många gradienter |
| Ta bort rutor | Rörelsen ser mindre mjuk ut | Demonstrationsvideos, animationer med många stillbilder | Animationer som kräver flyt |
| Minska storlek | Detaljer blir suddigare | Originalstorleken är tydligt större än den som visas | Innehåll med små texter som måste vara tydliga |
| Byt format | Oftast bättre | Webb, plattformar där du har kontroll | Plattformer som bara accepterar GIF |
Logiken bakåt är: gör det som inte skadar eller nästan inte skadar först, och gå sedan vidare efter behov. Om de två första stegen är tillräckligt små behöver du inte offra färger, bildfrekvens och storlek.
De första två stegen kan ImgZilla göra åt dig i batch
Om du har en samling GIF – samlade emojier, demonstrationsbilder i dokument, webbmaterial – är det tråkigt att släpa in dem i verktyg en och en.
ImgZilla är ett macOS-baserat verktyg för bildkomprimering. När det hanterar GIF använder det de två första stegen i tabellen:
- Baserat på gifsicle: Först hög nivå av bildrutesoptimering (samma som
-O3), sedan lätt LZW med förlust (samma som--lossy=40). - Ingen minskning av färger, rutor eller storlek. Animationen ser exakt likadan ut, men filen är mindre.
- Komprimerar på plats: Filnamn, sökväg och format ändras inte.
demo.gifsom refereras i dokument eller webb blir fortfarandedemo.gifefter komprimering. - Dra hela mappen i: Den skannar rekursivt undermappar och hanterar GIF tillsammans med JPG, PNG, WebP osv.
- Komprimerar inte om det inte går att spara mer: Om en fil redan är optimerad och komprimeringen är mindre än 0,4% markeras den som "minst" och behålls oförändrad.
- Flyttar original till papperskorgen: Om du inte är nöjd, högerklicka för att "flytta tillbaka".
- Kör helt lokalt: Ingen uppladdning till server, ingen gräns för antal filer – även gigantiska skärminspelningar kan hanteras.
Hur mycket som kan sparas beror på hur GIF:en exporterades ursprungligen. Skärminspelningar utan bildrutesoptimering där den mesta är stilla sparar oftast mest; redan professionellt komprimerade GIF:er kan ha liten utrymme kvar, eller så markeras de som "minst" – detta är normalt.
Vad ImgZilla inte gör
För att "animationen ska se likadan ut" gör ImgZilla inte steg 3–6 åt dig. Om de två första stegen fortfarande gör filen för stor, t.ex. för att den måste ligga under en viss gräns, måste du själv välja vad du vill offra:
bash
Med gifsicle kommandorad: ner till 128 färger, bredd ner till 640, starkare komprimering
gifsicle -O3 --lossy=80 --colors 128 --resize-width 640 input.gif -o output.gif
Använd ffmpeg för att konvertera GIF till MP4 (ofta betydligt mindre)
ffmpeg -i input.gif -movflags +faststart -pix_fmt yuv420p
-vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" output.mp4
Att ta bort rutor eller klippa längd kräver att du väljer ruta för ruta, vilket är lättare att göra visuellt med verktyg som ezgif.
En bättre vana: Exportera inte för stora GIF:er i första hand
De tre sista tipsen hjälper dig att slippa komprimera ofta i framtiden:
- Minska fönstret innan du skärminspelar, och spela in bara det område du behöver, inte hela Retina-skärmen.
- Välj 10–15 fps vid export, de flesta demonstrationer klarar detta.
- Komprimera direkt efter export genom att ta bort bildrutesoptimering och lätt LZW – detta steg behöver ingen bedömning och är lätt att låta verktyget göra i batch.
GIF är ett gammalt format, men det är fortfarande den största gemensamma nämnaren för "autoplay överallt". Istället för att fundera på att sluta med det, låt varje GIF bara ta den plats den behöver.
ImgZilla stöder för närvarande endast macOS (12.3 och nyare) och kan laddas ner från Mac App Store. Den kostnadsfria versionen kan komprimera 10 bilder per dag, och endast lyckade komprimeringar räknas – dra bara i en mapp fylld med GIF:er och se hur mycket som kan sparas.