Lecture vidéo sur le Web : bonnes pratiques en matière de diffusion vidéo (partie 2)

Dans mon article précédent, j'ai examiné les tendances vidéo sur le Web aujourd'hui, en utilisant les données de l'archive HTTP. J'ai constaté que de nombreux sites Web diffusent le même contenu vidéo sur mobile et sur ordinateur, et que de nombreux flux vidéo sont diffusés à des débits trop élevés pour être lus sur des connexions 3G. Nous avons également découvert que certains sites Web téléchargent automatiquement des vidéos sur des appareils mobiles, ce qui nuit aux plans de données des clients, à la durée de vie de la batterie, pour des vidéos qui pourraient ne jamais être lues.

TL;DR : Dans cet article, nous examinons les techniques permettant d'optimiser la vitesse et la livraison de la vidéo à vos clients, et fournissons une liste de 9 meilleures pratiques pour vous aider à diffuser vos ressources vidéo.

Métriques de lecture vidéo

Il existe 3 principales métriques de lecture vidéo utilisées aujourd'hui :

1. Heure de démarrage de la vidéo
2. Décrochage vidéo
3. Qualité vidéo

Étant donné que les fichiers vidéo sont volumineux, l'optimisation de la vidéo pour qu'elle soit aussi petite que possible conduira à une livraison vidéo plus rapide, accélérant le démarrage de la vidéo, réduisant le nombre de décrochages et minimisant l'effet de la qualité de la vidéo livrée. Bien sûr, nous devons équilibrer la vitesse de démarrage et le décrochage avec la troisième mesure de qualité (et les vidéos de qualité supérieure utilisent généralement plus de données).

Démarrage vidéo

Lorsqu'un utilisateur appuie sur lecture sur une vidéo, il s'attend à pouvoir regarder la vidéo rapidement. Selon Conviva (un leader de l'analyse des mesures vidéo), au premier trimestre de 2018, 14 % des vidéos n'ont jamais commencé à être lues (soit 2,4 milliards de lectures vidéo) après que l'utilisateur a appuyé sur la lecture.

2,3 % des vidéos (400 millions de requêtes vidéo) n'ont pas pu être lues après que l'utilisateur a appuyé sur le bouton de lecture. 11,54% (2B jeux) ont été abandonnés par l'utilisateur après avoir appuyé sur play. Essayons de décomposer ce qui pourrait causer ces problèmes.

Échec de la lecture vidéo

Les échecs de lecture vidéo représentaient 2,3 % de toutes les lectures vidéo. Qu'est-ce qui pourrait mener à cela? Dans les données HTTP Archive, nous constatons que 0,3 % de toutes les requêtes vidéo entraînent une réponse HTTP 4xx ou 5xx. Un certain pourcentage échoue donc en raison de mauvaises URL ou de mauvaises configurations de serveur. Un autre problème potentiel (qui n'est pas observé dans les données HTTP Archive) sont les vidéos bloquées par la géolocalisation (bloquées en fonction de l'emplacement du spectateur et de la licence du fournisseur pour afficher la vidéo dans ces paramètres régionaux).

Abandon de lecture vidéo

Le rapport Conviva indique que 11,5 % de toutes les lectures vidéo seraient lues, mais que le client a abandonné la lecture avant que la vidéo ne commence à jouer. Le problème ici est que la vidéo n'est pas livrée assez rapidement au client et qu'il abandonne. Il existe de nombreuses études sur le Web mobile où de longs délais entraînent l'abandon des pages Web, et il semble que le même effet se produise également avec la lecture vidéo.

Les recherches d'Akamai montrent que les téléspectateurs attendront 2 secondes, mais pour chaque seconde suivante, 5,8 % des téléspectateurs abandonnent la vidéo.

Alors, qu'est-ce qui cause des problèmes de lecture vidéo ? En général, les fichiers plus volumineux prennent plus de temps à télécharger, ce qui retardera la lecture. Regardons quelques façons d'accélérer la lecture des vidéos. Pour réduire le nombre de vidéos abandonnées au démarrage, nous devons "alléger" ces fichiers au mieux, afin qu'ils se téléchargent (et commencent à jouer) rapidement.

MP4 : préchargement vidéo

Pour assurer une lecture rapide sur le Web, une option consiste à précharger la vidéo sur l'appareil à l'avance. De cette façon, lorsque votre client clique sur "jouer", la vidéo est déjà téléchargée et la lecture sera rapide. HTML propose un attribut preload avec 3 options possibles : auto , metadata et none .

preload = auto

Lorsque votre vidéo est livrée avec preload="auto" , le navigateur télécharge l'intégralité du fichier vidéo et le stocke localement. Cela permet une grande amélioration des performances pour le démarrage de la vidéo, puisque la vidéo est disponible localement sur l'appareil, et aucune interférence réseau ne ralentira le démarrage.

Cependant, preload="auto" ne doit être utilisé que s'il existe une forte probabilité que la vidéo soit visionnée. Si la vidéo réside simplement sur votre page Web et qu'elle est téléchargée à chaque fois, cela ajoutera une importante pénalité de données à vos utilisateurs mobiles, ainsi qu'une augmentation de vos coûts de serveur/CDN pour la diffusion de l'intégralité de la vidéo à tous vos utilisateurs.

Ce site Web a une section intitulée "Galerie vidéo" avec plusieurs vidéos. Chaque vidéo de cette section a un préchargement défini sur auto , et nous pouvons visualiser leur téléchargement dans la cascade WebPageTest sous forme de lignes horizontales vertes :

Il existe une section appelée "Galerie vidéo", et les fichiers de cette petite section du site Web représentent 14,6 millions (83%) du téléchargement de la page. Les chances qu'une (parmi de nombreuses) vidéos soient lues sont probablement assez faibles, et donc l'utilisation de preload="auto" ne génère que beaucoup de trafic de données pour le site.

Dans ce cas, il est peu probable qu'une seule de ces vidéos soit visionnée, pourtant toutes sont entièrement téléchargées, ajoutant 14,8 Mo de contenu au site mobile (83 % du contenu de la page). Pour les vidéos qui ont une forte probabilité de lecture (peut-être > 90 % des pages vues entraînent une lecture vidéo) : le préchargement de la vidéo entière est une très bonne idée. Mais pour les vidéos qui ont peu de chances d'être lues, preload="auto" n'entraînera qu'un tonnage supplémentaire de contenu via vos serveurs et vers les appareils mobiles (et de bureau) de vos clients.

preload="metadata"

Lorsque l'attribut preload="metadata" est utilisé, un premier segment de la vidéo est téléchargé. Cela permet au joueur de connaître la taille de la fenêtre vidéo, et peut-être d'avoir une seconde ou 2 de vidéo téléchargée pour une lecture immédiate. Le navigateur effectue simplement une 206 (demande partielle) du contenu vidéo. En stockant une petite quantité de données vidéo sur l'appareil, le temps de démarrage de la vidéo est réduit, sans impact important sur la quantité de données transférées.

Sur Chrome, les métadonnées sont le choix par défaut si aucun attribut n'est choisi.

Remarque : Cela peut toujours conduire à une grande quantité de vidéo à télécharger, si la vidéo est volumineuse.

Par exemple, sur un site Web mobile avec une vidéo définie sur preload="metadata" , nous ne voyons qu'une seule demande de vidéo :

Et la demande est un téléchargement partiel, mais il en résulte toujours 2,7 Mo de vidéo à télécharger car la vidéo complète est en 1080p, 150 secondes et 97 Mo (nous parlerons de l'optimisation de la taille de la vidéo dans les sections suivantes).

Donc, je recommanderais que preload="metadata" ne soit toujours utilisé que lorsqu'il y a une probabilité assez élevée que la vidéo soit visionnée par vos utilisateurs, ou si la vidéo est petite.

preload="none"

L'option de téléchargement la plus économique pour les vidéos, car aucun fichier vidéo n'est téléchargé lorsque la page est chargée. Cela ajoutera potentiellement un retard dans la lecture, mais entraînera un chargement de page initial plus rapide Pour les sites avec de nombreuses vidéos sur une seule page, il peut être judicieux d'ajouter une affiche à la fenêtre vidéo et de ne télécharger aucune vidéo tant qu'elle expressément demandé par l'utilisateur final. Toutes les vidéos YouTube intégrées sur des sites Web ne téléchargent jamais de contenu vidéo tant que le bouton de lecture n'est pas enfoncé, se comportant essentiellement comme si preload="none" .

Preload Best Practice : n'utilisez preload="auto" que s'il y a une forte probabilité que la vidéo soit visionnée. En général, l'utilisation de preload="metadata" fournit un bon équilibre entre l'utilisation des données et le temps de démarrage, mais doit être surveillée pour une utilisation excessive des données.

Conseils de lecture vidéo MP4

Maintenant que la vidéo a commencé, comment pouvons-nous nous assurer que la lecture vidéo peut être optimisée pour ne pas caler et continuer à jouer. Encore une fois, l'astuce consiste à s'assurer que la vidéo est aussi petite que possible.

Regardons quelques astuces pour optimiser la taille des téléchargements vidéo. Plusieurs dimensions de vidéo peuvent être optimisées pour réduire la taille de la vidéo :

l'audio

Les fichiers vidéo sont divisés en différents "flux" - le plus courant étant le flux vidéo. Le deuxième flux le plus courant est la piste audio qui se synchronise avec la vidéo. Dans certaines applications de lecture vidéo, le flux audio est délivré séparément ; cela permet à différentes langues d'être livrées de manière transparente.

Si votre vidéo est lue de manière silencieuse (comme un GIF en boucle ou une vidéo d'arrière-plan), la suppression du flux audio de la vidéo est un moyen rapide et facile de réduire la taille du fichier. Dans un exemple de vidéo d'arrière-plan, le fichier complet était de 5,3 Mo, mais la piste audio (qui n'est jamais entendue) était de près de 300 Ko (5% du fichier) En éliminant simplement l'audio, le fichier sera livré rapidement sans perdre octets.

42% des fichiers MP4 trouvés sur HTTP Archive n'ont pas de flux audio.

Meilleure pratique : supprimez les pistes audio des vidéos qui sont lues en mode silencieux.

Encodage vidéo

Lors de l'encodage d'une vidéo, il existe des options pour réduire la qualité vidéo (nombre de pixels par image ou images par seconde). Réduire une vidéo de haute qualité pour l'adapter au Web est facile à faire et n'affecte généralement pas la qualité fournie à vos utilisateurs finaux. Cet article n'est pas assez long pour une discussion approfondie de toutes les différentes techniques de compression disponibles pour la vidéo. Dans les encodeurs x264 et x265 , il existe un terme appelé C onstant R ate Factor (CRF). L'utilisation d'un CRF de 23-28 donnera généralement un bon compromis compression/qualité et constitue un excellent premier pas dans le domaine de la compression vidéo

Taille de la vidéo

La taille de la vidéo peut être affectée par de nombreuses dimensions : longueur, largeur et hauteur (vous pouvez probablement également inclure l'audio ici).

Durée de la vidéo

La durée de la vidéo n'est généralement pas une fonctionnalité qu'un développeur Web peut ajuster. Si la vidéo doit être lue pendant trois minutes, elle sera lue pendant trois minutes. Dans les cas où la vidéo est exceptionnellement longue, des outils tels que preload="none" ou le streaming de la vidéo peuvent permettre de télécharger initialement une plus petite quantité de données afin de réduire le temps de chargement de la page.

Dimensions de la vidéo

18 % de toutes les vidéos trouvées dans l'archive HTTP sont identiques sur mobile et sur ordinateur. Ceux qui ont travaillé avec une conception Web réactive savent comment l'optimisation des images pour différentes fenêtres d'affichage peut réduire considérablement les temps de chargement, car la taille des images est beaucoup plus petite pour les écrans plus petits.

Il en va de même pour la vidéo. Un site Web avec une vidéo d'arrière-plan de 30 Mo 2560×1226 aura du mal à télécharger la vidéo sur mobile (probablement sur ordinateur aussi !). Le redimensionnement de la vidéo réduit considérablement la taille des fichiers et peut même permettre la diffusion de trois ou quatre vidéos d'arrière-plan différentes :

Maintenant, malheureusement, les navigateurs ne prennent pas en charge les requêtes multimédias pour la vidéo en HTML, ce qui signifie que cela ne fonctionne tout simplement pas :

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

Par conséquent, nous devrons créer un petit wrapper JS pour diffuser les vidéos souhaitées sur différentes tailles d'écran. Mais avant d'y aller...

Télécharger une vidéo, mais la cacher

Un autre retour aux premiers sites Web réactifs consiste à télécharger des images en taille réelle, mais à les masquer sur les appareils mobiles. Vos clients bénéficient de tout le délai de téléchargement des images volumineuses (et de l'accès au forfait de données mobiles, à la décharge supplémentaire de la batterie, etc.), et aucun des avantages de voir réellement l'image. Cela se produit assez fréquemment avec la vidéo sur mobile. Ainsi, au fur et à mesure que nous écrivons notre script, nous pouvons nous assurer que les petits écrans ne demandent jamais la vidéo qui n'apparaîtra pas en premier lieu.

Vidéos de qualité Retina

Vous pouvez avoir différentes vidéos pour différentes densités d'écran d'appareil. Cela peut entraîner un temps supplémentaire pour télécharger les vidéos pour vos clients mobiles. Vous souhaiterez peut-être empêcher les vidéos Retina sur des appareils à écran plus petit ou sur des appareils avec une bande passante réseau limitée, de revenir à des vidéos de qualité standard pour ces appareils. Des outils tels que l'API d'informations réseau peuvent vous fournir le débit du réseau et vous aider à décider de la qualité vidéo que vous souhaitez proposer à votre client.

Téléchargement de différents types de vidéo en fonction de la taille de l'appareil et de la qualité du réseau

Nous venons de couvrir quelques façons d'optimiser la diffusion de films sur des écrans plus petits, et avons également noté l'incapacité de la balise vidéo à choisir entre les types de vidéo, voici donc un extrait JS rapide qui utilisera la largeur de l'écran pour :

• Ne pas diffuser de vidéo sur des écrans inférieurs à 500 px ;
• Diffusez de petites vidéos pour les écrans 500-1400 ;
• Diffusez une vidéo de plus grande taille sur tous les autres appareils.

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

Ce script divise les écrans de l'utilisateur en trois options :

1. En dessous de 500 pixels, aucune vidéo n'est affichée.
2. Entre 500 et 1400, nous avons une vidéo plus petite.
3. Pour les écrans de plus de 1400 pixels de large, nous avons une vidéo plus grande.

Notre page propose une vidéo réactive avec deux tailles différentes : une pour les mobiles et une autre pour les écrans de la taille d'un ordinateur de bureau. Les utilisateurs mobiles bénéficient d'une excellente qualité vidéo, mais le fichier ne fait que 2,6 Mo, par rapport à la vidéo de 10 Mo pour le bureau.

GIF animés

Les GIF animés sont de gros fichiers. Alors que les aGIF et les fichiers vidéo compressent les données selon les dimensions de largeur et de hauteur, seuls les fichiers vidéo ont une compression (sur l'axe temporel souvent plus grand). Les aGIF « parcourent » rapidement les images GIF statiques. Ce manque de compression ajoute une quantité importante de données. Heureusement, il est possible de remplacer les aGIF par une vidéo en boucle, ce qui permet d'économiser potentiellement des Mo de données pour chaque requête.

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

Dans Safari, il existe une approche encore plus sophistiquée : vous pouvez placer un mp4 en boucle dans la balise de l'image, comme ceci :

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

Dans ce cas, Safari lira le GIF animé, tandis que Chrome (et les autres navigateurs prenant en charge WebP) liront le WebP animé, avec un retour au GIF animé. Vous pouvez en savoir plus sur cette approche dans l'excellent article de Colin Bendell.

Vidéos tierces

L'un des moyens les plus simples d'ajouter une vidéo à votre site Web consiste simplement à copier/coller le code d'un service de partage de vidéos et à le placer sur votre site. Cependant, tout comme pour l'ajout d'un tiers à votre site, vous devez être vigilant quant au type de contenu ajouté à votre page et à la manière dont cela affectera le chargement de la page. Beaucoup de ces widgets "collez simplement ceci dans votre code HTML" ajoutent des centaines de Ko de JavaScript. D'autres téléchargeront le film entier (pensez preload="auto" ), et certains feront les deux.

Meilleures pratiques pour les vidéos tierces : Faites confiance, mais vérifiez. Examinez la quantité de contenu ajouté et son impact sur le temps de chargement de votre page. De plus, le comportement peut changer, alors suivez régulièrement vos analyses.

Démarrage du streaming

Lorsqu'un flux vidéo est demandé, le serveur fournit un fichier manifeste au lecteur, répertoriant tous les flux disponibles (avec des informations sur les dimensions et le débit). Dans le streaming HLS, le lecteur choisit généralement le premier flux de la liste pour commencer la lecture. Par conséquent, le flux positionné en premier dans le fichier manifeste doit être optimisé pour le démarrage de la vidéo à la fois sur mobile et sur ordinateur (ou peut-être que des fichiers manifestes alternatifs doivent être livrés sur mobile plutôt que sur ordinateur).

Dans la plupart des cas, le démarrage est optimisé en utilisant un flux de qualité inférieure pour commencer la lecture. Une fois que le lecteur a téléchargé quelques segments, il a une meilleure idée du débit disponible et peut sélectionner un flux de meilleure qualité pour les segments ultérieurs. En tant qu'utilisateur, vous avez probablement vu cela - où les premières secondes d'une vidéo semblent très pixélisées, mais quelques secondes après le début de la lecture, la vidéo s'accentue.

En examinant 1 065 fichiers manifestes livrés aux appareils mobiles à partir de l'archive HTTP, nous constatons que 59 % des vidéos ont un débit binaire initial inférieur à 1,2 MBPS - et sont susceptibles de commencer à diffuser sans trop de retard à des débits de données 3G de 1,6 MBPS. 11 % utilisent un débit compris entre 1,2 et 1,6 MBPS — ce qui peut ralentir le démarrage en 3G, et 30 % ont un débit supérieur à 1,6 MBPS — et sont incapables de lire à ce débit sur une connexion 3G. Sur la base de ces données, il semble qu'environ 41 % de toutes les vidéos ne seront pas en mesure de maintenir le débit binaire initial sur mobile, ce qui rallongera le délai de démarrage et augmentera éventuellement le nombre de blocages pendant la lecture.

Meilleure pratique de démarrage en streaming : assurez-vous que votre débit binaire initial dans le fichier manifeste est celui qui fonctionnera pour la plupart de vos clients. Si le lecteur doit changer de flux au démarrage, la lecture sera retardée et vous perdrez des vues vidéo.

Alors, que se passe-t-il lorsque le débit binaire de la vidéo est proche (ou supérieur) du débit disponible ? Après quelques secondes de téléchargement sans qu'un segment vidéo terminé soit prêt pour la lecture, le lecteur arrête le téléchargement et choisit une vidéo à débit binaire de qualité inférieure, puis recommence le processus. L'action de télécharger un segment vidéo puis de l'abandonner entraîne un retard de démarrage supplémentaire, ce qui entraînera l'abandon de la vidéo.

Nous pouvons visualiser cela en créant des manifestes vidéo avec différents débits initiaux. Nous testons 3 scénarios différents : en commençant par le plus bas (215 KBPS), le moyen (600 KBPS) et le débit le plus élevé (2,6 MBPS).

Lorsque vous commencez avec la vidéo de qualité la plus basse, la lecture commence à 11 secondes. Après quelques secondes, le lecteur commence à demander un flux de meilleure qualité et l'image devient plus nette.

Lors du démarrage avec le débit le plus élevé (test sur une connexion 3G à 1,6 Mbps), le lecteur se rend rapidement compte que la lecture ne peut pas avoir lieu et passe à la vidéo au débit le plus bas (215 KBPS). La vidéo commence à jouer à 17s. Il y a un délai de 6 secondes et la qualité vidéo est la même que celle fournie lors du premier test.

L'utilisation de la vidéo de qualité moyenne permet un peu de compromis, la vidéo commence à jouer à 13 secondes (2 secondes plus lentement), mais est de haute qualité dès le début - et il n'y a pas de saut d'une vidéo pixélisée à une vidéo de qualité supérieure.

Meilleure pratique pour le démarrage vidéo : Pour une lecture plus rapide, commencez avec le flux de qualité la plus basse. Pour les vidéos plus longues, vous pouvez envisager d'utiliser un flux de "qualité moyenne" au début pour fournir une vidéo nette au démarrage (avec un délai légèrement plus long).

Résultats WebPageTest : le flux vidéo initial est faible, moyen et élevé (de haut en bas). La vidéo démarre le plus rapidement avec la vidéo de qualité la plus basse. Il est important de noter que la vidéo de démarrage de haute qualité à 17 s est de la même qualité que la vidéo de démarrage de faible qualité à 11 s.

Diffusion : lecture continue

Lorsque le lecteur vidéo peut déterminer le flux vidéo optimal pour la lecture et que le flux est inférieur à la vitesse du réseau disponible, la vidéo sera lue sans problème. Il existe des astuces qui peuvent aider à garantir que la vidéo sera diffusée de manière optimale. Si nous examinons l'entrée de manifeste suivante :

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

La ligne d'information signale que ce flux a un débit binaire de 913 KBPS et une résolution de 640 × 360. Si nous regardons l'URL vers laquelle cette ligne pointe, nous voyons qu'elle fait référence à une vidéo 600k. L'examen des fichiers vidéo montre que la vidéo est de 600 KBPS et que le manifeste surestime le débit binaire.

Surestimer le débit binaire de la vidéo

• PRO
  Surestimer le débit binaire garantira que lorsque le joueur choisit un flux, la vidéo se téléchargera plus rapidement que prévu et que la mémoire tampon se remplira plus rapidement que prévu, réduisant ainsi la possibilité d'un blocage.
• CONTRE
  En surestimant le débit binaire, la vidéo livrée sera un flux de qualité inférieure. Si nous regardons la liste complète des débits signalés par rapport aux débits réels :

Pour les utilisateurs disposant d'une connexion de 1,6 Mbps, le lecteur choisira le débit binaire de 913 KBPS, desservant la vidéo client de 600 KBPS. Cependant, si les débits avaient été signalés avec précision, le débit de 950 KBPS serait utilisé et aurait probablement été diffusé sans problème. Bien que les choix ici évitent les décrochages, ils réduisent également la qualité de la vidéo livrée au consommateur.

Meilleure pratique : une petite surestimation du débit binaire vidéo peut être utile pour réduire le nombre de décrochages lors de la lecture. Cependant, une valeur trop élevée peut entraîner une lecture de qualité réduite.

Testez la vidéo Neilsen dans le navigateur et voyez si vous pouvez la faire sauter d'avant en arrière.

Conclusion

Dans cet article, nous avons parcouru plusieurs façons d'optimiser les vidéos que vous présentez sur vos sites Web. En suivant les bonnes pratiques illustrées dans cet article :

1. preload="auto"
   À n'utiliser que s'il y a une forte probabilité que cette vidéo soit regardée par vos clients.
2. preload="metadata"
   Par défaut dans Chrome, mais peut toujours entraîner des téléchargements de fichiers vidéo volumineux. Utiliser avec précaution.
3. Vidéos silencieuses (GIF en boucle ou vidéos d'arrière-plan)
   Supprimez le canal audio
4. Dimensions de la vidéo
   Envisagez de diffuser des vidéos de tailles différentes sur un mobile via un ordinateur. Les vidéos seront plus petites, se téléchargeront plus rapidement et vos utilisateurs ne verront probablement pas la différence (la charge de votre serveur diminuera également !)
5. Compression de vidéo
   N'oubliez pas de compresser les vidéos pour vous assurer qu'elles sont livrées
6. Ne "masquez" pas les vidéos
   Si la vidéo ne s'affiche pas, ne la téléchargez pas.
7. Auditez régulièrement vos vidéos tierces
8. Streaming
   Commencez avec un flux de qualité inférieure pour assurer un démarrage rapide. (Pour les vidéos plus longues, envisagez un débit moyen pour une meilleure qualité au démarrage)
9. Streaming
   Il est normal d'être prudent sur le débit binaire pour éviter le décrochage, mais allez trop loin et les flux fourniront une vidéo de qualité inférieure.

Vous constaterez que la vidéo sur votre page est rationalisée pour une diffusion optimale et que vos clients seront non seulement ravis de la vidéo que vous présentez, mais profiteront également d'un temps de chargement de page plus rapide dans l'ensemble.