Perché una GIF di tre secondi pesa più del video da cui viene
Pubblicato il 07/07/2026 · 14 min di lettura · Strumenti per file
Daniel Okonkwo — Sviluppatore front-end e redattore Tech presso Allin
Performance web · Formati di file
Verificato su 4 fonti
Perché una GIF memorizza ogni fotogramma come un'immagine completa. Niente compensazione del movimento, niente fotogramma di riferimento, niente di tutto il macchinario che permette a un codec video di descrivere il secondo fotogramma come una piccola correzione del primo. La specifica del 1989 ammette al massimo 256 colori per fotogramma — il campo della tavolozza codifica la propria dimensione come potenza di due, e il massimo è 2⁸ — e gli indici dei pixel sono impacchettati con LZW, un compressore generalista. La dimensione segue quindi una formula che puoi fare a mente: byte ≈ larghezza × altezza × fotogrammi × bit per pixel ÷ 8, dove i bit per pixel sono ciò che sopravvive a LZW: circa 3 per riprese di camera ordinarie e ben meno di 1 per una registrazione dello schermo il cui sfondo non si muove mai. Prendi i valori predefiniti di questo strumento: 480 pixel di larghezza, 12 fotogrammi al secondo, 8 secondi. Un clip 16:9 diventa 480 × 270; 12 × 8 fa 96 fotogrammi; sono 12,4 milioni di pixel, e a 3 bit ciascuno vengono circa 4,7 MB. Il clip che l'ha prodotta, a un banalissimo 800 kbit/s, pesava 0,8 MB a piena risoluzione e a 30 fotogrammi al secondo. Le tre leve sono durata, cadenza e dimensioni, e solo l'ultima è quadratica: dimezzare la larghezza riduce a un quarto il conteggio dei pixel. Se il posto in cui pubblichi accetta video, pubblica il video.
Una GIF non ha una vera compressione video: ogni fotogramma è un'immagine intera, con un tetto di 256 colori. Ne esce un'aritmetica che puoi fare a mente — larghezza per altezza per numero di fotogrammi — e tre leve da tirare quando la casella di caricamento dice che il file è troppo grande.
Un formato del 1989 che non ha mai imparato il movimento
La specifica GIF89a descrive un'animazione come una sequenza di immagini con un ritardo fra l'una e l'altra. È tutto il modello. Nessuna nozione di scena che persiste, nessun vettore che dica al decodificatore che questo blocco di pixel è quello del fotogramma precedente spostato di undici pixel a sinistra. I codec video moderni mettono quasi tutta la loro astuzia esattamente in quell'idea, ed è da lì che viene quasi tutta la loro compressione: in un'inquadratura di qualcuno che parla, il muro dietro la testa viene trasmesso una volta e poi solo richiamato per trecento fotogrammi. Una GIF non ha modo di richiamare nulla.
C'è un'eccezione rudimentale, e vale la pena conoscerla perché spiega perché certe GIF si comportano molto meglio di quanto l'aritmetica preveda. Un fotogramma può essere scritto come un rettangolo più piccolo posto a uno scostamento, e i pixel non cambiati dal fotogramma precedente possono essere marcati trasparenti invece che memorizzati. FFmpeg — il motore che questo strumento usa — abilita entrambe le cose per impostazione predefinita. Su una registrazione dello schermo in cui un cursore attraversa una finestra ferma, è enorme: quasi tutto il fotogramma collassa a nulla. Su riprese di camera, dove il rumore del sensore fa sì che praticamente ogni pixel differisca un po' dal precedente, non risparmia quasi niente. Questa sola distinzione spiega perché le stesse impostazioni producono una GIF da 300 kB da una cattura schermo e una da 5 MB da un clip girato a mano.
L'aritmetica, e dove sta l'unico numero morbido
Byte ≈ larghezza × altezza × fotogrammi × b ÷ 8. Tutto ciò che sta a destra è esatto tranne b, il numero di bit che ogni pixel costa dopo che LZW ha fatto il suo lavoro. Prima della compressione ogni pixel è un indice in una tavolozza di al più 256 colori, quindi parte da 8 bit. Su contenuto fotografico retinato LZW di solito lo porta fra 2 e 5, ed è per questo che la cosa onesta è prendere b = 3 per una prima stima e accettare che la risposta sia buona a meno di un fattore due. Sembra sciatto finché non si nota che è lo stesso fattore due che si otterrebbe indovinando un bitrate video, e che basta per sapere se sei a una regolazione dal tuo limite o a quattro.
Una cosa che lo strumento non fa è misurare i colori del tuo clip. Una catena GIF di qualità fa due passaggi: uno per costruire una tavolozza dai pixel realmente presenti, l'altro per proiettarci sopra i fotogrammi. Questo strumento fa un solo passaggio, quindi i 256 posti vengono riempiti da una tabella generica e non dalle tue riprese. La conseguenza visibile sono bande nei cieli, nelle sfumature e negli incarnati, e una leggera ruvidità nelle zone scure. La conseguenza invisibile riguarda la dimensione, e taglia in entrambi i sensi: una tavolozza generica retina di più, e la retinatura aggiunge rumore ad alta frequenza che LZW detesta, il che spinge b verso l'alto. Se il tuo clip ha pochi colori in partenza — un'animazione di logo, un grafico, una finestra di terminale — niente di tutto ciò morde e il file uscirà molto sotto la stima.
La casella della larghezza non è una casella della dimensione
Digiti una larghezza; lo strumento calcola l'altezza dalla forma del clip. Per un clip orizzontale 16:9, 480 dà 480 × 270 — 129 600 pixel per fotogramma. Per un video di telefono ripreso in verticale, la stessa 480 dà 480 × 853, cioè 409 440 pixel per fotogramma: più del triplo, a parità di numero digitato nella stessa casella. È il motivo più comune per cui una GIF esce inaspettatamente enorme, ed è invisibile nell'interfaccia, che mostra solo una delle due dimensioni.
La correzione sta in una riga di aritmetica. Se vuoi che un clip verticale pesi quanto uno orizzontale largo 480, chiedi 270 di larghezza: 270 × 480 fa di nuovo esattamente 129 600 pixel. Più in generale, decidi un budget di pixel per fotogramma invece che una larghezza. Qualcosa fra 120 000 e 150 000 pixel per fotogramma sta comodo in una finestra di chat qualunque sia la forma — cioè 480 × 270 orizzontale, 270 × 480 verticale o 360 × 360 quadrato — e poi ti restano da discutere solo cadenza e durata.
La cadenza che hai chiesto probabilmente non è quella che hai ottenuto
Questa è pura archeologia di formato e frega tutti. La specifica GIF89a memorizza la pausa prima del fotogramma successivo in centesimi di secondo — il campo, con parole sue, «indica il numero di centesimi (1/100) di secondo da attendere». Non c'è unità più fine né frazionaria. Quindi una cadenza è riproducibile solo se 100 si divide esattamente per essa. Nell'intervallo offerto da questo strumento, ciò significa 2, 4, 5, 10, 20 e 25 fotogrammi al secondo, e nient'altro.
Il valore predefinito 12 non è fra questi. Un dodicesimo di secondo è 8,33 centesimi, e il file può contenere solo 8 o 9 — cioè 12,5 o 11,1 fotogrammi al secondo in riproduzione, per cui il tuo clip di otto secondi dura 7,68 o 8,64 secondi. Nessuno che guardi una GIF di gatti se ne accorgerà. Chi guarda un conto alla rovescia, un metronomo, un cronometro sul giro o una registrazione dello schermo in cui dimostri un difetto di temporizzazione, sì eccome. Trenta è peggio: un trentesimo di secondo è 3,33 centesimi, il file tiene 3, e la riproduzione esce a 33,3 fotogrammi al secondo — undici per cento veloce. Se il tempo conta, scegli 10, 20 o 25 e il file suona alla cadenza che hai chiesto.
Quando la risposta giusta non è una GIF
La dimensione di un video segue un'altra formula, molto più gentile: byte = bitrate × secondi ÷ 8. Otto secondi a 800 kbit/s fanno 800 kB, e 800 kbit/s comprano un clip perfettamente guardabile a piena risoluzione e trenta fotogrammi al secondo. È quasi sei volte meno della GIF costruita sugli stessi otto secondi a un quinto della risoluzione e a un terzo della cadenza — e il video ha l'audio, se lo vuoi. Ogni app di messaggistica, ogni forum moderno, ogni tracciatore di ticket e ogni social riproducono MP4 e WebM in linea e li ripetono a richiesta. Il ciclo in riproduzione automatica che sul web oggi si chiama «una GIF» è, nove volte su dieci, un MP4 muto.
Tieni quindi la GIF per i casi in cui non si accetta altro, e ce ne sono di veri: un wiki o un gestore di ticket che prende solo immagini in allegato, un client di posta che non incorpora video, un vecchio forum il cui editor ha un pulsante immagine e nulla più, un README reso da qualche parte che elimina i tag video. In quei posti la GIF non è una scelta nostalgica: è l'unica immagine in movimento che sopravvive al viaggio. Ovunque altrove, convertire in GIF significa pagare da cinque a dieci volte i byte per perdere l'audio, la maggior parte dei colori e metà dei fotogrammi.
Due piccole cose su questo strumento in particolare
Parte sempre dal secondo zero. La casella della durata è un tetto sull'uscita, non una finestra che puoi far scorrere: gli otto secondi che ottieni sono i primi otto del file. Se il momento che vuoi è a 0:42, taglia prima il clip con lo strumento di taglio e dagli il pezzo tagliato. Non è un limite che si aggira con una durata maggiore: mettere il massimo a 30 dà i primi trenta secondi e una GIF che nessuno può pubblicare da nessuna parte.
E la dimensione che riporta è misurata in unità da 1 048 576 byte pur chiamandole MB. È un mebibyte con l'etichetta di un megabyte, una sciatteria vecchissima e diffusissima. Qui conta in un solo punto: un limite espresso come 10 000 000 byte è 9,54 dei «MB» dello strumento, quindi un file che lo strumento annuncia fiero come 10,0 MB supera quel limite di quasi mezzo megabyte. Quando punti a un tetto rigido, punta il cinque per cento sotto e smetti di pensare alle unità.
| Impostazioni | Fotogrammi e pixel | Dimensione attesa |
|---|---|---|
| 480 × 270, 12 f/s, 8 s — i valori predefiniti | 96 fotogrammi · 12,4 megapixel | circa 4,7 MB |
| 480 × 270, 10 f/s, 5 s | 50 fotogrammi · 6,5 megapixel | circa 2,4 MB |
| 400 × 225, 10 f/s, 5 s | 50 fotogrammi · 4,5 megapixel | circa 1,7 MB |
| 320 × 180, 10 f/s, 4 s | 40 fotogrammi · 2,3 megapixel | circa 0,86 MB |
| 240 × 135, 5 f/s, 3 s | 15 fotogrammi · 0,49 megapixel | circa 0,18 MB |
| Stessa larghezza su un clip verticale: 480 × 853, 12 f/s, 8 s | 96 fotogrammi · 39,3 megapixel | circa 14,7 MB |
| Non una GIF: gli stessi 8 s in MP4 o WebM a 800 kbit/s | 240 fotogrammi a piena risoluzione, con l'audio | esattamente 0,8 MB |
Domande frequenti
- Si possono mettere più di 256 colori in una GIF?
- Sull'intero file sì; dentro un fotogramma no. La specifica permette a ogni blocco immagine di portare la propria tavolozza locale, quindi un'animazione di venti fotogrammi potrebbe in linea di principio usare venti tavolozze e toccare diverse migliaia di colori distinti in tutto. Ma ogni singolo fotogramma resta limitato a 256, e una tavolozza locale costa fino a 768 byte a ogni cambio. In pratica sul video rende pochissimo, perché l'occhio confronta i fotogrammi vicini e una tavolozza che cambia fra l'uno e l'altro produce sfarfallio visibile. Il guadagno maggiore alla portata di un codificatore GIF non sono più colori ma colori scelti meglio: una tavolozza misurata sulle tue riprese reali invece di una tabella generica.
- La mia GIF è ancora troppo grande e ho già ridotto la larghezza. E adesso?
- Taglia poi la durata, quindi la cadenza, in quest'ordine. Durata e cadenza sono entrambe lineari nel numero di fotogrammi, quindi rendono lo stesso per unità — ma un clip più corto è quasi sempre un clip migliore, mentre una cadenza più bassa è un degrado visibile sotto gli 8 fotogrammi al secondo circa, dove il movimento inizia a leggersi come una presentazione di diapositive. Due secondi a 10 fotogrammi al secondo sono venti fotogrammi, e venti fotogrammi da 320 × 180 a 3 bit fanno 432 kB. Se nemmeno così ci sta, la conclusione onesta è che il contenuto non comprime: guarda se sono riprese di camera con sfondo in movimento e, se lo sono, ritaglia stretto su ciò che conta oppure accetta che serva un video.
- La GIF mantiene l'audio?
- No, e non potrà mai: il formato non ha traccia audio né un posto dove metterne una. Vale la pena dirlo ad alta voce perché è un fallimento silenzioso — nulla ti avverte, la conversione riesce, e te ne accorgi pubblicando un clip il cui senso intero era una battuta. Se era l'audio che volevi condividere, la risposta è un video, oppure l'audio da solo: questo sito ha uno strumento che estrae la colonna sonora da un file video in MP3, AAC o WAV senza toccare l'immagine.
- Perché la mia GIF è granulosa nelle zone scure mentre il video sembrava a posto?
- Perché 256 colori devono coprire l'intero percorso dal nero al bianco, e in una scena scura la maggior parte dell'immagine si accalca in una manciata di essi. Il codificatore colma il vuoto retinando — spargendo pixel di due colori disponibili per fingerne un terzo — e nelle zone scure piatte quello spargimento si legge come grana. Costa anche in dimensione, perché la retinatura è rumore ad alta frequenza e il rumore ad alta frequenza è proprio ciò che LZW non sa comprimere. Due cose aiutano: schiarire o ritagliare il clip prima di convertire, così che meno parte viva nella zona schiacciata, e preferire contenuti con colori piatti e ben distinti. Nulla lo risolve del tutto dentro il formato, il che è un motivo in più perché la risposta sia spesso un video.
- Il video esce dal mio computer mentre gira?
- No. La conversione gira nella pagina, in una compilazione di FFmpeg in WebAssembly, e il motore stesso è servito da questo sito e non da una rete di terzi — quindi nemmeno il suo download una tantum consegna il tuo indirizzo a qualcun altro. C'è una conseguenza visibile da attendersi: la prima conversione di una sessione scarica circa 32 MB di motore e ci mette un po', e tutte le successive partono subito. E c'è un test che chiude la questione senza doverci credere: carica la pagina, spegni la rete e converti un clip. Se funziona ancora, non è stato caricato nulla.
Articoli che potrebbero interessarti
Tutte le guide →Strumenti correlati
Le dimensioni esatte riportate qui — audio non compresso, audio a bitrate fisso, conteggio dei pixel — sono aritmetica e reggeranno. Le dimensioni compresse sono stime: quanto una GIF o un codec senza perdita riesca a stringere dipende dalle tue riprese e dalla tua registrazione, non dal formato da solo. Prendile come ordine di grandezza, lancia lo strumento e leggi il numero che stampa.
Fonti
- W3C — Graphics Interchange Format Version 89a — Graphic Control Extension (delay in hundredths of a second), colour table sizing, and LZW image data
- FFmpeg — Codecs documentation — the gif encoder's gifflags: picture offsetting and inter-frame transparency detection, both enabled by default
- FFmpeg — ffmpeg documentation — -t as an output option stops writing once the output duration is reached, and -ss is what moves the start point
- FFmpeg — Filters documentation — the fps and scale filters, and the lanczos scaling flag this tool uses
Hai notato un errore in questo articolo?