12k
All articles

Comment remplacer les GIF animés par des vidéos MP4

Remplacez les GIF animés par une vidéo MP4 ou WebM avec autoplay muted loop playsinline, plus conversion ffmpeg et conseils LCP.

OpenReplay Team
OpenReplay Team
Comment remplacer les GIF animés par des vidéos MP4

Pour remplacer un GIF animé par une vidéo, convertissez le clip en MP4 H.264 et en WebM VP9, puis intégrez les deux avec <video autoplay muted loop playsinline>, en plaçant la <source> WebM en premier.

Si Lighthouse a signalé votre page produit ou votre documentation pour cause de contenu animé, la cause est généralement un GIF issu d’un enregistrement d’écran pesant plusieurs mégaoctets. Cet article explique pourquoi le GIF perd la bataille du poids, la conversion (outil navigateur ou ffmpeg, à vous de choisir), le balisage exact, l’effet de ce remplacement sur le LCP, et les cas où le GIF reste le bon choix.

Points clés

  • Un GIF animé stocke chaque image comme une image quasi complète limitée à 256 couleurs, ce qui le prive totalement de la compression interimage sur laquelle reposent les codecs vidéo.
  • C’est muted qui autorise les navigateurs à lancer la lecture automatique, et playsinline qui empêche iOS de forcer la vidéo en plein écran.
  • Les navigateurs lisent la première <source> qu’ils peuvent décoder, et non la plus légère : la source WebM doit donc précéder le fallback MP4.
  • Depuis Chrome 116, une <video> sans poster peut être considérée comme l’élément LCP, et le temps enregistré correspond au moment où sa première image s’affiche à l’écran.
  • Le gain de poids dépend entièrement du clip ; mesurez le vôtre avant et après plutôt que de vous fier à un pourcentage annoncé.

Pourquoi le GIF est-il le mauvais conteneur pour l’animation ?

Un GIF animé stocke chaque image comme une image quasi complète, avec une palette limitée à 256 couleurs par image ; il ne bénéficie donc d’aucune compression interimage, alors que les formats vidéo ont été conçus autour de ce principe, et il est décodé de façon logicielle tandis que H.264 et VP9 disposent de chemins de décodage matériel sur la plupart des appareils. La spécification GIF89a indique clairement que le format n’a pas été conçu pour porter de l’animation et ne l’autorise que de manière limitée ; la lecture en boucle est venue plus tard, ajoutée par les navigateurs. Voilà toute la leçon d’histoire qu’il vous faut.

La conséquence pratique est que quelques secondes d’enregistrement d’écran atteignent couramment plusieurs mégaoctets en GIF, contre quelques centaines de kilooctets en vidéo. Lighthouse le signale : le conseil de conversion GIF vers vidéo figure désormais dans l’insight Improve image delivery à partir de Lighthouse 13.

Une conversion réelle, avec des chiffres réels

Le guide web.dev sur le sujet publie un exemple honnête, converti avec les commandes présentées ci-dessous : un GIF source de 3,7 Mo est devenu un MP4 de 551 Ko et un WebM de 341 Ko. Le gain dépend entièrement du contenu du clip, de sa fréquence d’images et de ses dimensions : un pourcentage mesuré sur un fichier ne se généralise donc pas au vôtre.

FichierTaille
GIF source3,7 Mo
MP4 (H.264, CRF 25)551 Ko
WebM (VP9, CRF 41)341 Ko

Considérez ces chiffres comme un point de données, pas comme une règle. Une séquence très animée ne se compresse pas comme un enregistrement de terminal essentiellement statique. Faites passer votre propre clip par les étapes ci-dessous et comparez le nombre d’octets avant de vous engager.

Comment remplacer un GIF par une vidéo : créer les fichiers

Il vous faut deux fichiers : un MP4 pour une lecture universelle et un WebM, généralement plus léger. Chaque étape propose un outil navigateur et une commande ffmpeg équivalente.

Étape 1 : du GIF au MP4. Utilisez le convertisseur GIF vers MP4, qui s’exécute localement dans votre navigateur, ou ffmpeg :

ffmpeg -i input.gif -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2" \
  -vcodec libx264 -pix_fmt yuv420p -b:v 0 -crf 25 -f mp4 output.mp4

-pix_fmt yuv420p garantit que le fichier reste lisible partout, et le CRF s’échelonne de 0 à 51, une valeur plus basse signifiant une meilleure qualité, -b:v 0 désactivant la limite de débit en mode CRF. Le filtre de recadrage est le contournement proposé par web.dev face au refus par libx264 des dimensions en pixels impaires.

Étape 2 : le fichier WebM, destiné à la seconde <source>. Dans le navigateur, passez le MP4 que vous venez de créer au convertisseur MP4 vers WebM. Avec ffmpeg, encodez plutôt directement depuis le GIF d’origine, afin que le clip ne soit pas compressé deux fois :

ffmpeg -i input.gif -c:v libvpx-vp9 -b:v 0 -crf 41 output.webm

L’échelle CRF de VP9 diffère de celle de x264, ce qui explique pourquoi 41 constitue ici une valeur par défaut raisonnable et non un réglage de basse qualité.

Étape 3 : réglages facultatifs. Si le résultat reste lourd, réduisez-le en résolution et en qualité avec le compresseur vidéo, ou avec ffmpeg :

ffmpeg -i output.mp4 -vf scale=640:-2 -crf 28 -movflags faststart smaller.mp4

-movflags faststart déplace les métadonnées du MP4 au début du fichier afin que la lecture puisse commencer avant la fin du téléchargement.

Le balisage qui se comporte comme un GIF

Pour qu’une vidéo se comporte comme un GIF, utilisez <video autoplay muted loop playsinline> : c’est muted qui autorise les navigateurs à lancer la lecture automatique, et playsinline qui empêche iOS de forcer la vidéo en plein écran.

<video autoplay muted loop playsinline width="640" height="360">
  <source src="clip.webm" type="video/webm">
  <source src="clip.mp4" type="video/mp4">
</video>

La politique de lecture automatique de Chrome autorise une vidéo muette à démarrer d’elle-même, et bloque la lecture automatique avec son tant que le visiteur n’a pas interagi avec le site. La politique vidéo de WebKit pour iOS n’autorise la lecture automatique sans geste utilisateur que pour les vidéos muettes ou dépourvues de piste audio, et l’iPhone a besoin de playsinline pour lire le clip sur place. L’ordre des sources compte, car les navigateurs ne choisissent pas la meilleure <source> : ils lisent la première qu’ils savent décoder, d’où le WebM, plus léger, placé en premier. Cet ordre est sans risque partout : le tableau WebM de caniuse indique une prise en charge complète dans Safari 16 sur macOS et dans Safari sur iOS à partir de la version 17.4 ; les mises en garde de 2018 concernant Apple et WebM ne s’appliquent donc plus. Les attributs width et height réservent l’espace de mise en page, la même courtoisie vis-à-vis du CLS que celle accordée à une image.

Lorsqu’un de ces attributs manque, l’échec est silencieux : aucune erreur en console, aucune icône d’image cassée, juste une première image figée. Le session replay montre la page telle que chaque utilisateur l’a réellement vue, seul moyen fiable de détecter une vidéo en lecture automatique qui n’a jamais démarré en production.

Quel est l’effet de ce remplacement sur le Largest Contentful Paint ?

Remplacer <img> par <video> change l’élément susceptible d’être votre candidat LCP. Les anciennes recommandations affirmaient qu’une <video> sans poster était invisible pour le LCP, mais cela a changé avec Chrome 116 : le changelog des métriques Chromium indique qu’un élément vidéo est désormais éligible au même titre qu’une image, son horodatage étant pris au moment où la première image s’affiche à l’écran. N’ajoutez donc pas un poster dans le seul but d’influencer la métrique : une vidéo en lecture automatique affiche sa première image immédiatement, et l’image du poster ne serait jamais vue. Si votre animation principale est le plus grand élément, sa mesure LCP dépend maintenant de la rapidité d’arrivée de cette première image, une raison de plus de garder des fichiers légers.

Quand le GIF garde-t-il l’avantage ?

Le GIF garde l’avantage là où vous ne maîtrisez pas le balisage : messages de chat, clients de messagerie et README GitHub affichent un GIF en ligne mais n’intègrent pas de vidéo en lecture automatique. Dans ces environnements, la portabilité prime sur le poids de la page, et la bonne démarche consiste à compresser le GIF avec perte plutôt qu’à le convertir. L’option --lossy de gifsicle (anciennement le projet distinct giflossy) échange des artefacts contre du poids :

gifsicle -O3 --lossy=80 -o smaller.gif input.gif

Des valeurs de perte plus élevées autorisent davantage d’artefacts et des fichiers plus petits ; ajustez jusqu’à ce que le rendu cesse d’être acceptable, puis revenez légèrement en arrière.

Conclusion

Sur toute page dont vous maîtrisez le balisage, l’animation a sa place dans un élément <video> doté de deux sources, et non dans un GIF. Choisissez le GIF le plus lourd de votre site, faites-le passer par les étapes de conversion ci-dessus et comparez vous-même le nombre d’octets ; puis déployez le balisage à quatre attributs avec le WebM en premier et consultez le replay d’une session réelle pour confirmer qu’il se lit effectivement.

FAQ

Puis-je servir uniquement un MP4 et me passer du fichier WebM ?

Oui. Un MP4 H.264 au format de pixels yuv420p se lit dans tous les navigateurs modernes : un élément vidéo à source unique fonctionne donc partout, sans rien casser. La version WebM est une optimisation de poids, pas une exigence de compatibilité : VP9 produit généralement un fichier plus léger à qualité comparable. Déployez d'abord le MP4, puis ajoutez la source WebM au-dessus plus tard si le poids de la page vous préoccupe toujours.

Pourquoi ma vidéo ne démarre-t-elle toujours pas automatiquement, même avec autoplay, muted, loop et playsinline ?

C'est une politique du user agent qui bloque la lecture, pas votre balisage. Safari sur iOS suspend la lecture automatique lorsque l'appareil est en mode économie d'énergie et affiche à la place un bouton de lecture ; les modes d'économie de batterie ou de données d'autres navigateurs peuvent se comporter de façon similaire. Détectez-le en JavaScript : video.play() renvoie une promesse, gérez donc le rejet en affichant les contrôles ou une image de repli statique plutôt qu'une image figée.

L'attribut loading='lazy' fonctionne-t-il sur l'élément vidéo ?

Dans les navigateurs basés sur Chromium, oui. Chrome, Edge et Opera diffèrent le téléchargement d'une vidéo lazy, la récupération de son poster et sa lecture automatique jusqu'à ce que l'élément approche de la zone visible, et MDN documente l'attribut. Un ajout correspondant à la spécification HTML est en cours, et Firefox comme WebKit ont exprimé une position favorable vis-à-vis de ce standard, mais aucun ne l'a encore implémenté. Les navigateurs qui ne le prennent pas en charge ignorent simplement l'attribut et chargent immédiatement : l'ajouter aux vidéos de remplacement de GIF situées hors écran est donc sans risque aujourd'hui.

Le WebP animé constitue-t-il un bon compromis entre le GIF et la vidéo ?

Parfois. Le WebP animé fonctionne à l'intérieur d'une simple balise img, prend en charge la couleur 24 bits au lieu de la palette de 256 couleurs du GIF, et produit généralement des fichiers plus légers que le GIF équivalent. Mais il n'égale pas un véritable codec vidéo : H.264 ou VP9 compresse bien mieux un enregistrement d'écran. Utilisez le WebP animé lorsque l'environnement impose une balise image mais accepte les formats modernes, et la vidéo partout où vous maîtrisez le balisage.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — self-hosted, with full data ownership.

Star on GitHub

We use cookies to improve your experience. By using our site, you accept cookies.