Performances des vidéos

Dans le module précédent, vous avez découvert certaines techniques d'optimisation des performances liées aux images. Il s'agit d'un type de ressource largement utilisé sur le Web, qui peut consommer une bande passante importante si vous ne prenez pas soin de l'optimiser et de tenir compte de la fenêtre d'affichage de l'utilisateur.

Cependant, les images ne sont pas le seul type de média couramment utilisé sur le Web. Les vidéos sont un autre type de média populaire souvent utilisé sur les pages Web. Avant d'examiner certaines des optimisations possibles, il est important de comprendre d'abord le fonctionnement de l'<video> élément.

Fichiers source vidéo

Lorsque vous travaillez avec des fichiers multimédias, le fichier que vous reconnaissez sur votre système d'exploitation (.mp4, .webm, etc.) est appelé conteneur. Un conteneur comporte un ou plusieurs flux. Dans la plupart des cas, il s'agit du flux vidéo et du flux audio.

Vous pouvez compresser chaque flux à l'aide d'un codec. Par exemple, un video.webm peut être un conteneur WebM contenant un flux vidéo compressé à l'aide de VP9 et un flux audio compressé à l'aide de Vorbis.

Il est utile de comprendre la différence entre les conteneurs et les codecs, car cela vous permet de compresser vos fichiers multimédias en utilisant beaucoup moins de bande passante. Cela réduit les temps de chargement globaux des pages et peut améliorer le LCP (Largest Contentful Paint) d'une page, qui est une métrique axée sur l'utilisateur et l'un des trois Core Web Vitals.

Vous pouvez compresser des fichiers vidéo à l'aide de FFmpeg :

ffmpeg -i input.mov output.webm

La commande précédente, aussi basique soit-elle lorsque vous utilisez FFmpeg, prend le fichier input.mov et génère un fichier output.webm à l'aide des options FFmpeg par défaut. La commande précédente génère un fichier vidéo plus petit qui fonctionne dans tous les navigateurs modernes. Vous pouvez réduire davantage la taille du fichier vidéo en modifiant les options vidéo ou audio proposées par FFmpeg. Par exemple, si vous utilisez un <video> élément pour remplacer un GIF, vous devez supprimer la piste audio :

ffmpeg -i input.mov -an output.webm

Si vous souhaitez affiner davantage les choses, FFmpeg propose l'option -crf lors de la compression de vidéos sans utiliser l'encodage à débit binaire variable. -crf signifie Constant Rate Factor (Facteur de débit constant). Il s'agit d'un paramètre qui ajuste le niveau de compression et qui accepte un entier dans une plage donnée.

Les codecs tels que H.264 et VP9 sont compatibles avec l'option -crf, mais son utilisation dépend du codec que vous utilisez. Pour en savoir plus, consultez Facteur de débit constant pour l'encodage de vidéos au format H.264 et Qualité constante pour l'encodage de vidéos au format VP9.

Formats multiples

Lorsque vous travaillez avec des fichiers vidéo, la spécification de plusieurs formats fonctionne comme solution de secours pour les navigateurs qui ne sont pas compatibles avec tous les formats modernes.

<video>
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

Étant donné que tous les navigateurs modernes sont compatibles avec le codec H.264, le format MP4 peut être utilisé comme solution de secours pour les navigateurs hérités. La version WebM peut utiliser le codec AV1 plus récent, qui n’est pas encore aussi largement compatible, ou le codec VP9 antérieur, qui est mieux compatible qu’AV1, mais qui ne compresse généralement pas aussi bien qu’AV1.

L'attribut poster

L'image poster d'une vidéo est ajoutée à l'aide de l'posterattribut sur l'<video> élément, qui indique aux utilisateurs le contenu de la vidéo avant le début de la lecture :

<video poster="poster.jpg">
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

Lecture automatique

Selon HTTP Archive, 20 % des vidéos sur le Web incluent l' autoplay attribut. autoplay est utilisé lorsqu'une vidéo doit être lue immédiatement, par exemple lorsqu'elle est utilisée comme arrière-plan vidéo ou comme remplacement de GIF animés.

Les GIF animés peuvent être très volumineux, en particulier s'ils comportent de nombreux frames avec des détails complexes. Il n'est pas rare que les GIF animés consomment plusieurs mégaoctets de données, ce qui peut être une charge importante sur la bande passante, qui serait mieux utilisée pour des ressources plus critiques. En règle générale, évitez les formats d'image animée, car <video> sont beaucoup plus efficaces pour ce type de média.

Si la lecture automatique de vidéos est une exigence pour votre site Web, vous pouvez utiliser l' autoplay attribut directement sur l'élément <video> :

<!-- This will automatically play a video, but
     it will loop continuously and be muted: -->
<video autoplay muted loop playsinline>
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

En combinant l'attribut poster avec l'API Intersection Observer, vous pouvez configurer votre page pour ne télécharger les vidéos que lorsqu'elles se trouvent dans la fenêtre d'affichage. L'image poster peut être un espace réservé d'image de faible qualité, tel que le premier frame de la vidéo. Une fois la vidéo affichée dans la fenêtre d'affichage, le navigateur commence à la télécharger. Cela peut améliorer les temps de chargement du contenu dans la fenêtre d'affichage initiale. En revanche, lorsque vous utilisez une image poster pour autoplay, vos utilisateurs reçoivent une image qui ne s'affiche que brièvement jusqu'à ce que la vidéo soit chargée et commence à être lue.

Lecture déclenchée par l'utilisateur

En règle générale, le navigateur commence à télécharger un fichier vidéo dès que l'analyseur HTML découvre l'élément <video>. Si vous avez des éléments <video> dans lesquels l' utilisateur lance la lecture, vous ne voulez probablement pas que la vidéo commence à être téléchargée tant que l'utilisateur n'a pas interagi avec elle.

Vous pouvez affecter ce qui est téléchargé pour les ressources vidéo à l'aide de l'<video> attribut preload :

• Définir preload="none" informe le navigateur qu'aucun contenu de la vidéo ne doit être préchargé.
• Définir preload="metadata" ne récupère que les métadonnées vidéo, telles que la durée de la vidéo et éventuellement d'autres informations rapides.

Définir preload="none" est probablement le cas le plus souhaitable si vous chargez des vidéos pour lesquelles les utilisateurs doivent lancer la lecture.

Dans ce cas, vous pouvez améliorer l'expérience utilisateur en ajoutant une image poster. Cela donne à l'utilisateur un contexte sur le contenu de la vidéo. De plus, si l'image poster est votre élément LCP, vous pouvez augmenter la priorité de l'image poster à l'aide de l'indication <link rel="preload"> avec fetchpriority="high" :

<link rel="preload" as="image" href="poster.jpg" fetchpriority="high">

Chargement différé

L'attribut loading=lazy est une nouveauté relativement récente en matière de performances vidéo. Comme pour le chargement différé des images au niveau du navigateur et pour les iFrames, cet attribut apporte les mêmes avantages aux vidéos pour leurs téléchargements poster et preload.

L'utilisation d'un attribut poster avec preload="none" ou preload="metadata" peut déjà éviter le téléchargement de la vidéo par défaut. L'attribut loading=lazy diffère même le téléchargement de l'image poster et des métadonnées jusqu'à ce que la vidéo se trouve dans la fenêtre d'affichage ou s'en approche.

Intégrations

Compte tenu de la complexité de l'optimisation et de la diffusion efficace de contenus vidéo, il est logique de vouloir déléguer le problème à des services vidéo dédiés tels que YouTube ou Vimeo. Ces services optimisent la diffusion des vidéos pour vous, mais l'intégration d'une vidéo à partir d'un service tiers peut avoir son propre effet sur les performances, car les lecteurs vidéo intégrés peuvent souvent diffuser de nombreuses ressources supplémentaires, telles que JavaScript.

Compte tenu de cette réalité, les intégrations vidéo tierces peuvent avoir un impact significatif sur les performances des pages. Selon HTTP Archive, les intégrations YouTube bloquent le thread principal pendant plus de 1,7 seconde pour le site Web médian. Le blocage du thread principal pendant de longues périodes est un problème d'expérience utilisateur grave qui peut avoir un impact sur l' interaction avec le prochain affichage (INP) d'une page. Toutefois, vous pouvez faire un compromis en ne pas charger l'intégration immédiatement lors du chargement initial de la page, et en créant plutôt un espace réservé pour l'intégration qui est remplacé par l'intégration vidéo réelle lorsque l'utilisateur interagit avec elle.

Vidéos de démonstration

Tester vos connaissances

À suivre : Optimiser les polices Web

Dans notre couverture de l'optimisation de types de ressources spécifiques, nous allons maintenant aborder les polices. L'optimisation des polices de votre site Web est souvent négligée, mais elle peut avoir un impact significatif sur la vitesse de chargement globale de votre site Web et sur des métriques telles que le LCP et le CLS (Cumulative Layout Shift).