Dans le module précédent, vous avez découvert certaines techniques de performance liées aux images, un type de ressource largement utilisé sur le Web, qui peut consommer une bande passante importante si vous ne prenez pas le soin de les optimiser et de prendre en compte la fenêtre d'affichage de l'utilisateur.
Cependant, les images ne sont pas le seul type de support couramment utilisé sur le Web. Les vidéos sont un autre type de support populaire souvent utilisé sur les pages Web. Avant d'examiner certaines des optimisations possibles, il est important de comprendre le fonctionnement de l'élément <video>.
Fichiers sources de la vidéo
Lorsque vous travaillez avec des fichiers multimédias, le fichier que vous reconnaissez dans votre système d'exploitation (.mp4, .webm, etc.) est appelé un conteneur. Un conteneur contient un ou plusieurs flux. Dans la plupart des cas, il s'agit du flux vidéo et 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.
Comprendre la différence entre les conteneurs et les codecs est utile, car cela vous aide à compresser vos fichiers multimédias en utilisant beaucoup moins de bande passante, ce qui réduit le temps de chargement global des pages et peut améliorer le Largest Contentful Paint (LCP), qui est une métrique centrée sur l'utilisateur et l'un des trois Core Web Vitals.
Pour compresser des fichiers vidéo, vous pouvez utiliser FFmpeg:
ffmpeg -i input.mov output.webm
La commande précédente, bien qu'elle puisse être basique lors de l'utilisation de FFmpeg, utilise 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 récents. Modifier les options vidéo ou audio proposées par FFmpeg peut vous aider à réduire encore davantage la taille du fichier d'une vidéo. Par exemple, si vous utilisez un élément <video> 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'indicateur -crf lors de la compression des vidéos sans utiliser l'encodage à débit variable. -crf est l'abréviation de Constant Rate Factor. Il s'agit d'un paramètre qui ajuste le niveau de compression en acceptant un entier dans une plage donnée.
Les codecs tels que H.264 et VP9 sont compatibles avec l'indicateur -crf, mais son utilisation dépend du codec que vous utilisez. Pour en savoir plus, consultez les articles sur le facteur de débit constant pour l'encodage des vidéos en H.264, ainsi que sur la qualité constante lors de l'encodage des vidéos en VP9.
Formats multiples
Lorsque vous utilisez des fichiers vidéo, la spécification de plusieurs formats fonctionne comme solution de remplacement 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 récents sont compatibles avec le codec H.264, le format MP4 peut être utilisé en remplacement pour les anciens navigateurs. La version WebM peut utiliser le codec AV1 plus récent, qui n'est pas encore aussi largement pris en charge, ou le codec VP9 antérieur, mieux compatible qu'AV1, mais qui n'est généralement pas compressé en parallèle à AV1.
Attribut poster
L'image poster d'une vidéo est ajoutée à l'aide de l'attribut poster sur l'élément <video>, qui indique aux utilisateurs le contenu de la vidéo avant le lancement de la lecture:
<video poster="poster.jpg">
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
</video>
Lecture automatique
D'après l'archive HTTP, 20% des vidéos sur le Web incluent l'attribut autoplay. autoplay est utilisé lorsqu'une vidéo doit être lue immédiatement (par exemple, lorsqu'elle est utilisée comme arrière-plan de la vidéo ou pour remplacer des GIF animés).
Les GIF animés peuvent être très volumineux, en particulier s'ils comportent de nombreux cadres comportant des détails complexes. Il n'est pas rare que les GIF animés consomment plusieurs mégaoctets de données, ce qui peut entraîner une consommation importante de la bande passante pour des ressources plus critiques. Vous devez généralement éviter les formats d'images animées, car les équivalents <video> sont beaucoup plus efficaces pour ce type de contenu multimédia.
Si la lecture automatique de vidéos est requise pour votre site Web, vous pouvez utiliser l'attribut autoplay directement dans 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 qu'elle ne télécharge des vidéos qu'une fois qu'elles se trouvent dans la fenêtre d'affichage.
L'image poster peut être un espace réservé d'image de basse qualité, comme la première image de la vidéo. Une fois que la vidéo apparaît dans la fenêtre d'affichage, le navigateur commence à la télécharger. Cela pourrait 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 débute la lecture.
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 a détecté l'élément <video>. Si vous disposez d'éléments <video> où l'utilisateur lance la lecture, vous ne souhaitez probablement pas que le téléchargement de la vidéo démarre tant que l'utilisateur n'a pas interagi avec.
Vous pouvez influer sur ce qui est téléchargé pour les ressources vidéo à l'aide de l'attribut preload de l'élément <video>:
- Le paramètre
preload="none"indique au navigateur qu'aucun contenu de la vidéo ne doit être préchargé. - Si vous définissez
preload="metadata", seules les métadonnées de la vidéo, telles que sa durée et éventuellement d'autres informations sommaires, sont récupérées.
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 permet de donner à l'utilisateur plus de contexte sur le sujet 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'indice <link rel="preload"> avec fetchpriority="high":
<link rel="preload" as="image" href="poster.jpg" fetchpriority="high">
Intégrations
Compte tenu de la complexité liée à l'optimisation et à la diffusion efficaces du contenu vidéo, il est logique de 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. Toutefois, l'intégration d'une vidéo provenant d'un service tiers peut avoir un impact sur les performances, car les lecteurs vidéo intégrés peuvent souvent utiliser 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 l'archive HTTP, les intégrations YouTube bloquent le thread principal pendant plus de 1,7 seconde pour le site Web médian. Bloquer le thread principal pendant de longues périodes est un problème sérieux de l'expérience utilisateur qui peut avoir une incidence sur l'Interaction to Next Paint (INP) d'une page. Toutefois, vous pouvez trouver un compromis en ne chargeant pas l'intégration immédiatement lors du chargement initial de la page, mais en créant un espace réservé qui sera remplacé par l'intégration vidéo réelle lorsque l'utilisateur interagit avec elle.
Démonstrations vidéo
Tester vos connaissances
L'ordre des éléments <source> dans un élément <video> parent ne détermine pas la ressource vidéo à télécharger.
L'attribut poster de l'élément <video> est considéré comme candidat au LCP.
Prochaine étape: Optimiser les polices Web
Poursuivons avec l'optimisation de types de ressources spécifiques : 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, ainsi que sur des métriques telles que le LCP et le CLS (Cumulative Layout Shift).