La règle de tri, avant tout le reste

Le GIF n'est pas pénalisé, il est simplement très cher à transporter. Google mesure une réduction de 64 % en passant un GIF animé en WebP avec perte, et l'exemple de référence de web.dev tombe de 3,7 Mo à 341 Ko en WebM, soit 91 % de moins. La règle de tri est simple : ne touchez qu'aux GIF animés de plus de 500 Ko, et en priorité à ceux visibles au chargement.

Ce qu'est le GIF, et pourquoi il compresse mal

Écran affichant une animation, format d'image animé

Le format date de 1987 et il a été conçu pour des connexions à quelques kilobits par seconde et des écrans à palette limitée. Il en garde trois caractéristiques structurelles, qu'aucun réglage ne corrige.

Ce que ça coûte, en chiffres

Deux sources officielles suffisent à cadrer le sujet, et elles ne disent pas tout à fait la même chose parce qu'elles ne comparent pas la même chose.

ConversionRéductionSource
GIF animé vers WebP avec perte64 % de moinsDocumentation WebP de Google
GIF animé vers WebP sans perte19 % de moinsDocumentation WebP de Google
GIF de 3,7 Mo vers MP4551 Ko, soit 85 % de moinsweb.dev
Le même GIF vers WebM341 Ko, soit 91 % de moinsweb.dev

La lecture est nette : la vidéo bat systématiquement l'image animée, parce qu'elle exploite la redondance entre les images successives. Le WebP animé est un compromis, utile quand on veut garder une balise image et le comportement d'un GIF sans toucher au code.

Ce que ça change côté SEO, précisément. Un GIF placé dans la partie visible au chargement devient souvent le plus gros élément de la page, donc l'élément que mesure le LCP. Trois mégaoctets à télécharger avant que le LCP soit validé rendent le seuil de 2,5 secondes inatteignable sur une connexion mobile, quelle que soit la qualité du serveur. Et comme le LCP est un signal Web essentiel, l'effet est direct. Voir les Core Web Vitals.

Trois alternatives, une par situation

Le mauvais réflexe est de tout convertir dans un format unique. Le bon choix dépend de ce que contient le fichier.

Votre GIF contientCe qu'il faut utiliserPourquoi
Une animation de plus de deux secondes, ou une capture d'écran animéeUne vidéo, en WebM avec repli MP4Le meilleur rapport poids sur qualité, et de loin. On y gagne aussi le chargement progressif.
Une courte animation qu'on veut garder dans une balise imageWebP animé64 % de moins qu'un GIF, aucun changement de code au-delà de l'extension. Support navigateur supérieur à 97 %.
Une image fixe enregistrée en GIF par habitudeWebP ou AVIFUn GIF fixe n'a aucun avantage sur quoi que ce soit. AVIF compresse encore mieux, avec une couverture navigateur d'environ 93 %.
Un logo, une icône, un schémaSVGVectoriel, net à toute taille, souvent quelques kilooctets, et modifiable en CSS.
Un pictogramme de moins de 10 KoRien du tout, laissez-leLe gain absolu est nul, le temps passé ne l'est pas.

Convertir, en pratique

Deux commandes suffisent pour la vidéo, et ce sont celles que recommande la documentation de web.dev.

Le paramètre -crf règle la qualité : plus il est bas, plus le fichier est lourd. Sur des captures d'écran, où l'on veut du texte lisible, je descends souvent à 20 pour le MP4, quitte à perdre un peu de compression.

Côté intégration, une vidéo qui doit se comporter comme un GIF a besoin de quatre attributs, et l'oubli du dernier casse la lecture automatique sur iPhone.

Chercher les fichiers lourds, pas les GIF

Je ne cherche pas les GIF, je cherche les fichiers lourds. Un tri des ressources par poids dans l'onglet réseau des outils de développement, ou un rapport Lighthouse qui remonte l'audit « utilisez des formats vidéo pour le contenu animé », suffit à identifier les deux ou trois fichiers qui portent tout le problème. Sur la grande majorité des sites, ces deux ou trois fichiers représentent plus de 80 % du gain possible, et le reste du travail sur les images n'est pas rentable tant qu'ils sont là. Le tri complet est décrit dans le poids des images et l'optimisation des images.

Un GIF animé n'est pas conforme au niveau A

Point rarement soulevé et pourtant décisif, parce qu'il ne se règle par aucune optimisation : le critère 2.2.2 des WCAG, « Pause, Stop, Hide », de niveau A, exige qu'un contenu qui bouge, démarre tout seul, dure plus de cinq secondes et s'affiche à côté d'autre chose, dispose d'un moyen de le mettre en pause, de l'arrêter ou de le masquer.

Un GIF animé n'offre aucun de ces trois moyens. Il démarre seul, il boucle indéfiniment, et le visiteur n'a aucune prise dessus. Une boucle de plus de cinq secondes place donc la page en non-conformité sur un critère de niveau A, c'est-à-dire le plus élémentaire des trois niveaux. Les techniques suffisantes citées par le W3C sont d'ailleurs explicites, puisqu'elles demandent de limiter l'animation à moins de cinq secondes ou de faire cesser le clignotement après un nombre défini de cycles.

La vidéo résout le problème que la conversion visait déjà. Une balise <video> accepte l'attribut controls, donc un bouton de pause, et se laisse arrêter par le visiteur. Le même fichier pèse dix fois moins et devient conforme. C'est l'argument que j'utilise quand la performance ne suffit pas à convaincre : l'accessibilité numérique n'est plus seulement une bonne pratique en France, elle relève d'obligations légales qui se sont étendues au secteur privé avec l'entrée en application de la directive européenne sur l'accessibilité, le 28 juin 2025.

Deux compléments, dans le même esprit. La requête média prefers-reduced-motion permet de ne pas déclencher l'animation pour les visiteurs qui ont demandé à leur système de réduire les animations, ce qu'un GIF ne sait pas faire. Et une animation placée près d'un texte à lire gêne la lecture de tout le monde, pas seulement des personnes sensibles au mouvement.

Les rares cas où le GIF reste défendable

Ils existent, et il faut les nommer pour ne pas transformer une bonne pratique en dogme.

L'e-mail. Les clients de messagerie ne lisent pas de vidéo, et beaucoup ne gèrent pas le WebP animé. Le GIF y reste le seul format d'animation qui fonctionne partout. C'est aujourd'hui son principal usage légitime.

Le pixel de suivi. Le GIF transparent d'un pixel pèse quelques dizaines d'octets et fait le travail. Personne n'a de raison d'y toucher.

Un contenu déjà lié depuis l'extérieur. Si un GIF est directement pointé par des liens ou intégré ailleurs, changer son URL casse ces liens. Servez la version optimisée à la même adresse plutôt que de renommer le fichier.

Ce que Google Images en fait

Question qui revient souvent : un GIF se positionne-t-il moins bien dans la recherche d'images ? Non, le format n'est pas un critère de classement. Ce qui compte dans Google Images est ailleurs : le texte alternatif, le nom du fichier, le contexte de la page qui héberge l'image, et la présence de l'image dans un sitemap image. Un GIF correctement décrit se positionne comme un JPEG correctement décrit. Voir l'attribut alt et le nom de fichier.

Questions fréquentes

Le format GIF pénalise-t-il le référencement ?
Pas en tant que format : Google n'applique aucune décote au GIF. Ce qui pénalise, c'est son poids, qui dégrade le LCP et consomme la donnée mobile de vos visiteurs. Un GIF animé de plusieurs mégaoctets placé en haut de page est un problème de performance mesurable, et c'est la performance qui compte, pas l'extension du fichier.
De combien un GIF s'allège-t-il en WebP ou en vidéo ?
Selon la documentation de Google, un GIF animé converti en WebP avec perte pèse 64 % de moins, et 19 % de moins en WebP sans perte. La conversion en vidéo va bien plus loin : l'exemple donné par web.dev passe d'un GIF de 3,7 Mo à 551 Ko en MP4 et 341 Ko en WebM, soit respectivement 85 % et 91 % de moins.
Faut-il remplacer tous les GIF de son site ?
Non, il faut trier par poids. Un petit GIF statique de quelques kilooctets ne mérite aucun travail. Ce qui compte, ce sont les GIF animés de plus de 500 Ko, en particulier ceux qui s'affichent dans la partie visible au chargement. Sur la plupart des sites, deux ou trois fichiers représentent la quasi-totalité du gain possible.
Le GIF est-il vraiment limité à 256 couleurs ?
Oui, chaque image d'un GIF utilise une palette d'au plus 256 couleurs. C'est ce qui explique les dégradés en bandes sur les photos et les aplats sales sur les captures d'écran. Sa transparence est également binaire : un pixel est opaque ou totalement transparent, sans niveau intermédiaire, d'où les bords en escalier sur un fond coloré.
Peut-on utiliser AVIF à la place ?
Oui pour les images fixes, où AVIF compresse mieux que WebP. Pour l'animation, je reste sur la vidéo : le décodage d'une séquence AVIF animée reste coûteux sur les téléphones d'entrée de gamme, et une balise vidéo apporte en plus le chargement progressif et le contrôle de la lecture. La couverture navigateur d'AVIF avoisine 93 % en 2026, contre plus de 97 % pour WebP.

Sources