Lecture vidéo sur le Web : l'état actuel de la vidéo (Partie 1)
Publié: 2022-03-10L'utilisation de la vidéo sur le Web augmente à mesure que les appareils et les réseaux deviennent plus rapides et plus capables de gérer le contenu vidéo. Les recherches montrent que les sites avec vidéo augmentent l'engagement de 80 %. Les sites de commerce électronique avec vidéo ont des conversions plus élevées que les sites sans vidéo.
Mais l'ajout de vidéo peut avoir un coût. Les vidéos (étant des fichiers plus volumineux) ajoutent au temps de chargement de la page, et les recherches sur les performances montrent que les pages plus lentes ont l'effet inverse de l'engagement et des conversions des clients. Dans cet article, j'examinerai les mesures importantes pour équilibrer les performances et la lecture vidéo sur le Web, j'examinerai comment la vidéo est utilisée aujourd'hui et je fournirai les meilleures pratiques en matière de diffusion de vidéo sur le Web.
L'une des premières étapes pour améliorer la satisfaction client consiste à accélérer le temps de chargement d'une page . Google a montré que les pages mobiles qui mettent plus de trois secondes à se charger perdent 53% de leur audience à cause de l'abandon. D'autres études montrent qu'en améliorant les performances du site, l'utilisation et les ventes augmentent.
L'ajout de vidéos à un site Web augmentera l'engagement, mais cela peut également ralentir considérablement le temps de chargement. Il est donc clair qu'un équilibre doit être trouvé entre l'ajout de vidéos sur votre site et le fait de ne pas trop affecter le temps de chargement.
Lecture recommandée : Liste de vérification des performances frontales 2018 [PDF, Pages Apple]
Vidéo sur le Web aujourd'hui
Pour examiner l'état de la vidéo sur le Web aujourd'hui, j'utiliserai les données de l'archive HTTP. L'archive HTTP utilise WebPageTest pour analyser les performances de 1,2 million de sites Web mobiles et de bureau toutes les deux semaines, puis stocke les données dans Google BigQuery.
Généralement, seule la page principale de chaque domaine est vérifiée (ce qui signifie www.cnn.com
est exécuté, mais pas www.cnn.com/politics
). Ces données peuvent nous aider à comprendre comment l'utilisation de la vidéo sur le Web affecte les performances des sites Web. Les tests mobiles sont exécutés sur un Motorola G4 émulé avec une connexion Internet 3G (1,6 MBPS vers le bas, 768 KBPS vers le haut, 300 ms RTT), et les tests de bureau exécutent Chrome sur une connexion par câble (5 MBPS vers le bas, 1 MBPS vers le haut, 28 ms RTT). J'utiliserai l'ensemble de données à partir du 1er août 2018.
Sites qui téléchargent des vidéos
Comme première étape pour étudier les sites avec vidéo, nous devrions regarder les sites qui téléchargent des fichiers vidéo lorsque la page se charge. Il existe 35 000 sites mobiles et 55 000 sites de bureau avec des téléchargements de fichiers vidéo dans l'ensemble de données HTTP Archive (soit 3 % de tous les sites mobiles et 4,5 % de tous les sites de bureau). En comparant le bureau au mobile, nous constatons que 30 000 de ces sites ont de la vidéo à la fois sur mobile et sur bureau (ce qui laisse environ 5 800 sites sur mobile sans vidéo sur le bureau).

La page mobile médiane avec vidéo pèse 7 Mo (583 % de plus que 1,2 Mo trouvé pour le site mobile médian). Cette augmentation n'est pas entièrement expliquée par la vidéo seule (2,5 Mo). Comme les sites avec vidéo ont tendance à être plus riches en fonctionnalités et visuellement attrayants, ils utilisent également plus d'images (le site médian a plus de 1 Mo de plus), CSS et Javascript. Le tableau ci-dessous montre également que le SpeedIndex médian (une mesure de la rapidité avec laquelle le contenu apparaît à l'écran) pour les sites avec vidéo est 3,7 secondes plus lent qu'un site mobile typique, prenant 11,5 secondes à charger.
Indice de vitesse | Octets totaux | Octets Vidéo | Octets CSS | Images d'octets | Octets JS | |
---|---|---|---|---|---|---|
Vidéo | 11544 | 6 963 579 | 2 526 098 | 80 327 | 1 596 062 | 708 978 |
tous les sites | 7780 | 1 201 802 | 0 | 40 648 | 449 585 | 336 973 |
Cela montre clairement que les sites qui sont plus interactifs et qui ont du contenu vidéo prennent (en moyenne) plus de temps à charger que les sites sans vidéo. Mais pouvons-nous accélérer la diffusion vidéo ? Que pouvons-nous apprendre d'autre des données disponibles ?
Hébergement vidéo
Lors de l'examen de la diffusion vidéo, les fichiers sont-ils diffusés à partir d'un CDN ou d'un fournisseur de vidéos, ou les développeurs hébergent-ils les vidéos sur leurs propres serveurs ? En examinant le domaine des vidéos diffusées sur mobile, nous constatons que 12 163 domaines sont utilisés pour diffuser des vidéos, ce qui indique qu'environ 49 % des sites diffusent leurs propres fichiers vidéo. Si nous empilons les domaines par fréquence, nous sommes en mesure de déterminer les solutions d'hébergement vidéo les plus courantes :
Domaine vidéo | cent | % |
---|---|---|
fbcdn.net | 116788 | 67% |
akamaihd.net | 11170 | 6% |
googlevideo.com | 10394 | 6% |
cloudinary.fr | 3170 | 2% |
amazonaws.com | 1939 | 1% |
cloudfront.net | 1896 | 1% |
pixfs.net | 1853 | 1% |
akamaized.net | 1573 | 1% |
tedcdn.com | 1507 | 1% |
contentabc.com | 1507 | 1% |
vimeocdn.ccom | 1373 | 1% |
dailymotion.com | 1337 | 1% |
teas.tv | 1022 | 1% |
youtube.com | 1007 | 1% |
adstatic.com | 998 | 1% |
Les principaux CDN et domaines Facebook, Akamai, Google, Cloudinary, AWS et Cloudfront ouvrent la voie, ce qui n'est pas surprenant. Cependant, il est intéressant de voir YouTube et Vimeo si loin dans la liste, car ce sont deux des sites de partage de vidéos les plus populaires.
Examinons la diffusion de vidéos sur YouTube, Vimeo et Facebook :
Nombre de vidéos YouTube
Par défaut, les pages avec une vidéo YouTube intégrée ne téléchargent aucun fichier vidéo - juste des scripts et une image d'espace réservé, de sorte qu'ils n'apparaissent pas dans une recherche de sites avec des téléchargements de vidéos. L'un des téléchargements Javascript pour le lecteur vidéo YouTube est www-embed-player.js
. En recherchant ce fichier, nous trouvons 69 000 instances sur 66 647 sites mobiles. Ces sites ont un SpeedIndex médian de 10 700 et une utilisation des données de 3,31 Mo - mieux que les sites avec vidéo téléchargée, mais toujours plus lent que les sites sans vidéo du tout. L'augmentation des données est directement associée à plus d'images et de Javascript (comme indiqué ci-dessous).
Indice de vitesse | Octets totaux | Octets Vidéo | Octets CSS | Images d'octets | Octets JS | |
---|---|---|---|---|---|---|
Vidéo | 11544 | 6 963 579 | 2 526 098 | 80 327 | 1 596 062 | 708 978 |
Tous les sites | 7780 | 1 201 802 | 0 | 40 648 | 449 585 | 336 973 |
Script YouTube | 10700 | 3 310 000 | 0 | 126 314 | 1 733 473 | 1 005 758 |
Nombre de vidéos Vimeo
Il y a 14 148 demandes de vidéos Vimeo dans HTTP Archive pour la lecture vidéo. Je ne vois que 5 848 requêtes pour le fichier player.js (au format https://f.vimeocdn.com/p/3.2.0/js/player.js
— ce qui implique qu'il y a peut-être de nombreuses vidéos sur une seule page, ou peut-être un autre emplacement pour le fichier du lecteur vidéo. Il existe 17 versions différentes du lecteur présentes dans HTTP Archive, les plus populaires étant 3.1.5 et 3.1.4 :
URL | cent |
---|---|
https://f.vimeocdn.com/p/3.1.5/js/player.js | 1832 |
https://f.vimeocdn.com/p/3.1.4/js/player.js | 1057 |
https://f.vimeocdn.com/p/3.1.17/js/player.js | 730 |
https://f.vimeocdn.com/p/3.1.8/js/player.js | 507 |
https://f.vimeocdn.com/p/3.1.10/js/player.js | 432 |
https://f.vimeocdn.com/p/3.1.15/js/player.js | 352 |
https://f.vimeocdn.com/p/3.1.19/js/player.js | 153 |
https://f.vimeocdn.com/p/3.1.2/js/player.js | 117 |
https://f.vimeocdn.com/p/3.1.13/js/player.js | 105 |
Il ne semble pas y avoir de gain de performances pour aucune bibliothèque Vimeo - toutes les pages ont des temps de chargement similaires.
Remarque : L'utilisation www-embed-player.js
pour YouTube ou https://f.vimeocdn.com/p/*/js/player.js
pour Vimeo sont de bonnes empreintes digitales pour les navigateurs avec un cache propre, mais si le client a déjà a parcouru un site avec une vidéo intégrée, ce fichier peut déjà être dans le cache du navigateur et ne sera donc pas redemandé. Mais, comme Andy Davies l'a récemment noté, ce n'est pas une hypothèse sûre à faire.
Nombre de vidéos Facebook
Il est surprenant que dans les données HTTP Archive, 67 % de toutes les requêtes vidéo proviennent du CDN de Facebook. Il s'avère que sur Chrome, les widgets Facebook tiers téléchargent 30 % de toutes les vidéos publiées à l'intérieur du widget (cet effet ne se produit pas dans Safari ou dans Firefox). Il s'avère qu'un widget tiers ajouté avec seulement quelques lignes de code est responsable de 57 % de toutes les vidéos vues dans l'archive HTTP.
Types de fichiers vidéo
La majorité des vidéos sur les pages testées sont des MP4. Si on regarde toutes les vidéos téléchargées (hors celles de Facebook), on obtient la vue suivante :
Extension de fichier | Nombre de vidéos | % |
---|---|---|
.mp4 | 48 448 | 53% |
.ts | 18 026 | 20% |
.webm | 3 946 | 4% |
14 926 | 16% | |
.m4s | 2 017 | 2% |
.mpg | 1 431 | 2% |
.mov | 441 | 0% |
.m4v | 407 | 0% |
.swf | 251 | 0% |
Parmi les fichiers sans extension, 10 000 sont des fichiers googlevideo.com
.
Que pouvons-nous apprendre sur ces fichiers ? Examinons chaque type de fichier pour en savoir plus sur le contenu fourni.
J'ai utilisé FFPROBE pour interroger les 34 000 fichiers MP4 uniques et obtenu des données pour 14 700 vidéos (de nombreuses vidéos avaient été modifiées ou supprimées au cours des 3 semaines entre la capture de l'archive HTTP et l'analyse).
Données vidéo MP4
Sur les 14 700 vidéos de l'ensemble de données, 8 564 ont des pistes audio (58 %). Les vidéos plus courtes qui se lisent automatiquement ou les vidéos qui se lisent en arrière-plan ne nécessitent pas d'audio, donc la suppression de la piste audio est un excellent moyen de réduire la taille du fichier (et d'accélérer la livraison) de vos vidéos.
Le prochain aspect le plus important pour télécharger rapidement une vidéo sont les dimensions. Plus les dimensions sont grandes (et dans le cas d'une vidéo, il y a trois dimensions à prendre en compte : width
× height
× time
), plus le fichier vidéo sera volumineux.

Durée de la vidéo MP4
La plupart des vidéos 14k étudiées sont courtes : la durée médiane (50e centile) est de 21s. Cependant, 10 % des vidéos interrogées durent plus de 2 minutes. Les cas d'utilisation ici seront bien sûr divisés, mais pour les courtes boucles vidéo ou les vidéos d'arrière-plan, les vidéos plus courtes utiliseront moins de données et se téléchargeront plus rapidement.

Largeur et hauteur de la vidéo MP4
Les dimensions de la vidéo à l'écran déterminent le nombre de pixels que chaque image devra utiliser. Le tableau ci-dessous montre les différentes largeurs de vidéo diffusées sur l'appareil mobile. (À noter, le Moto G4 a une taille d'écran de 1080×1920, et les pages sont toutes visualisées en mode portrait).

Comme le montrent les données, les deux largeurs vidéo les plus utilisées sont nettement plus grandes que l'écran G4 (lorsqu'il est tenu en mode portrait). 49 % de toutes les vidéos sont diffusées avec une largeur supérieure à 1 080 pixels. L'Alcatel 1x, un nouvel appareil Android Go, dispose d'un écran de 480 × 960 pixels. 77 % des vidéos livrées dans l'échantillon ont une largeur supérieure à 480 pixels.
À mesure que les dimensions des vidéos diminuent, la taille des fichiers diminue également (et donc le temps de livraison de la vidéo). C'est la principale raison de redimensionner les vidéos.
Pourquoi ces vidéos sont-elles si volumineuses ? Si nous corrélons les vidéos diffusées sur mobile et ordinateur, nous constatons que 18 % des vidéos diffusées sur mobile sont les mêmes vidéos diffusées sur ordinateur. C'est un "problème" résolu pour les images il y a des années avec des images réactives. En diffusant des vidéos de tailles différentes sur des appareils de tailles différentes, nous pouvons nous assurer que de belles vidéos sont diffusées, mais à une taille et une dimension qui ont du sens pour l'appareil.
Débit vidéo MP4
Le débit binaire de la vidéo transmise à l'appareil a un effet important sur la qualité de lecture de la vidéo. Les tests HTTP Archive sont exécutés sur une connexion 3G à une vitesse de téléchargement de 1,6 MBPS. Pour lire (sans caler), le téléchargement doit être plus rapide que la lecture. Fournissons 80 % du débit binaire disponible aux fichiers vidéo (1,3 MBPS). 47 % des vidéos de l'échantillon ont un débit binaire supérieur à 1,3 MBPS, ce qui signifie que lorsque ces vidéos sont lues sur une connexion 3G, elles sont plus susceptibles de caler, ce qui rend les clients mécontents. 27 % des vidéos ont un débit supérieur à 2,5 MBPS, 10 % sont supérieurs à 5 MBPS et 35 % des vidéos diffusées sur des appareils mobiles ont un débit supérieur à 10 MBPS. Il est peu probable que ces vidéos plus volumineuses soient lues sans caler sur de nombreuses connexions, fixes ou mobiles.

Ce qui conduit à des débits binaires plus élevés
Les vidéos plus grandes ont tendance à avoir un débit binaire plus important, car les vidéos de plus grande taille nécessitent beaucoup plus de données pour remplir les pixels supplémentaires sur l'appareil. Le croisement du débit binaire de chaque vidéo avec la largeur le confirme : les vidéos avec une largeur de 1280 (orange) et 1920 (gris) ont une distribution beaucoup plus large des débits binaires (plus de points de données à droite dans le graphique). La colonne marquée en jaune indique les 136 vidéos avec une largeur de 1920 et un débit entre 10 et 11 MBPS.

Si nous ne visualisons que les vidéos de plus de 1,6 MBPS, il devient clair que les résolutions d'écran plus élevées (1280 et 1920) sont responsables des vidéos à débit binaire plus élevé.

MP4 : HTTP contre HTTPS
HTTP2 a redéfini la diffusion de contenu avec des connexions multiplexées, où une seule connexion par serveur est requise. Pour les fichiers volumineux comme la vidéo, HTTP2 apporte-t-il une amélioration significative à la diffusion de contenu ? Si nous regardons les statistiques de l'archive HTTP :

En omettant les 116 000 vidéos Facebook (toutes envoyées via HTTP2), nous voyons qu'il s'agit d'une répartition d'environ 50/50 entre HTTP 1.1 et HTTP2. Cependant, HTTP1.1 peut utiliser HTTPS, et lorsque nous filtrons sur l'utilisation de HTTPS, nous constatons que 81 % des flux vidéo sont envoyés via HTTPS, HTTP2 étant légèrement plus utilisé que HTTPS1.1 (41 % : 36 %).

Comme vous pouvez le constater, la comparaison de la vitesse de diffusion vidéo HTTP et HTTP2 est un travail en cours.
Diffusion vidéo HLS
Le streaming vidéo à débit binaire adaptatif est un moyen idéal pour diffuser la vidéo à l'utilisateur final. Plusieurs versions de chaque vidéo sont construites avec des dimensions et des débits différents. La liste des flux disponibles est présentée à l'appareil de lecture, et le lecteur vidéo sur l'appareil peut choisir le flux le plus approprié en fonction de la taille de l'écran de l'appareil et des conditions de réseau disponibles. Il y a 1 065 fichiers manifestes (et 14 000 fichiers de flux vidéo) dans l'ensemble de données HTTP Archive que j'ai examiné.
Lecture de flux vidéo
L'un des paramètres clés du streaming vidéo est de faire démarrer la vidéo le plus rapidement possible. Alors que le fichier manifeste contient une liste des flux disponibles, le lecteur n'a aucune idée de la bande passante disponible du réseau au début de la lecture. Pour commencer à diffuser, et parce que le joueur doit choisir un flux, il choisit généralement le premier de la liste. Afin de faciliter un démarrage vidéo rapide, il est important de placer le flux correct en haut de votre fichier manifeste.
Remarque : L'utilisation de l'API Chrome Network Info pour générer des fichiers manifestes à la volée peut être un bon moyen d'optimiser rapidement le contenu vidéo au démarrage.
Une façon de s'assurer que la vidéo démarre rapidement est de commencer avec le segment vidéo de qualité la plus basse, car le téléchargement sera le plus rapide. La qualité vidéo initiale peut être pixélisée, mais à mesure que le lecteur comprend mieux la qualité du réseau, il peut rapidement s'adapter à un flux vidéo plus approprié (espérons-le de meilleure qualité). Dans cet esprit, examinons les débits binaires initiaux du flux dans l'archive HTTP.

La ligne rouge dans le graphique ci-dessus indique 1,5 MBPS (rappelez-vous que les tests mobiles sont exécutés à 1,6 MBPS, et non seulement le contenu vidéo est téléchargé). Nous voyons que 30,5 % de tous les flux (tout ce qui se trouve à gauche de la ligne) commencent avec un débit initial supérieur à 1,5 MBPS (et sont donc peu susceptibles d'être lus sur une connexion 3G) 17 % commencent au-dessus de 2 MBPS.
Que se passe-t-il lorsque le téléchargement de la vidéo est plus lent que la lecture réelle de la vidéo ? Dans un premier temps, le lecteur tentera de télécharger les fichiers au (trop) gros débit, mais en fonction de la vitesse de téléchargement, il se rendra compte du problème. Le lecteur passera alors au téléchargement d'une vidéo à débit binaire inférieur, de sorte que le téléchargement soit plus rapide que la lecture. Le problème est que la tentative de téléchargement initiale prend du temps et que l'ajout d'un délai au démarrage de la lecture vidéo entraîne l'abandon du client.
Nous pouvons également examiner les débits binaires les plus courants des fichiers .ts
(les fichiers contenant le contenu vidéo), pour voir quels débits finissent par être téléchargés sur mobile. Ces données incluent les débits initiaux et tout fichier ultérieur téléchargé lors de l'exécution de WebPageTest :

Nous pouvons voir deux principaux groupes de débits vidéo en streaming (100-300 KBPS, et un pic plus large de 300-1 000 MBPS). C'est là que nous nous attendons à ce que les flux apparaissent, étant donné que la vitesse du réseau est plafonnée à 1,6 MBPS.
En comparant les données au bureau, Mobile est clairement plus élevé aux débits binaires inférieurs, et les flux de bureau ont des pics élevés dans les plages 500-600 et 800-900 KBPS, qui ne sont pas observés dans le mobile.


Lorsque nous comparons les débits binaires initiaux observés (bleu) avec les fichiers réels téléchargés, il est très clair que pour les mobiles, le débit binaire diminue généralement pendant la lecture du flux, ce qui indique que la réduction du débit binaire initial pour les flux vidéo peut améliorer les performances de démarrage de la vidéo et éviter les décrochages. au début de la lecture de la vidéo. La vidéo de bureau semble également diminuer, mais il est également possible que certaines vidéos passent à des vitesses de lecture plus élevées.
Conclusion
Le contenu vidéo sur le Web augmente l'engagement et la satisfaction des clients. Les pages qui se chargent rapidement ont le même effet. L'ajout de vidéo à votre site Web ralentira le temps de rendu de la page, ce qui nécessitera un équilibre entre la charge globale de la page et le contenu vidéo. Pour réduire la taille de votre contenu vidéo, assurez-vous que vous disposez de versions adaptées aux dimensions de l'appareil mobile et utilisez des vidéos plus courtes lorsque cela est possible.
Si la lecture de vos vidéos n'est pas essentielle, suivez le chemin de YouTube et Vimeo - téléchargez toutes les pièces requises pour être prêtes pour la lecture, mais ne téléchargez aucun segment vidéo tant que l'utilisateur n'appuie pas sur lecture. Enfin, si vous diffusez de la vidéo, commencez par le réglage de qualité le plus bas pour garantir une lecture vidéo rapide.
Dans mon prochain article sur vidéo, je prendrai ces conclusions générales et approfondirai la manière de résoudre les problèmes potentiels avec des exemples.