HTML5 : les nouveaux attributs vidéo au crible L'attribut HTML5 @preload

Le dernier attribut que nous devons examiner est l'attribut @preload. Il remplace un précédent attribut appelé @autobuffer, booléen et donc incapable d'opérer une distinction entre les différents besoins de mise en mémoire tampon des utilisateurs. L'attribut @preload a été proposé en remplacement parce qu'il permet aux développeurs web de donner au navigateur des informations plus détaillées concernant les besoins des utilisateurs relatifs à la mise en mémoire tampon.

En général, vous n'utiliserez pas l'attribut @preload, qui se destine à des besoins spécifiques. Ces paragraphes ne concernent donc que les utilisateurs avancés.

Lorsqu'un navigateur web tombe sur un élément <video>, il doit décider de ce qu'il doit faire avec la ressource à laquelle il est lié.

Si l'élément <video> possède l'attribut @autoplay, le navigateur doit commencer à télécharger la ressource, configurer le pipeline de décodage vidéo, démarrer le décodage de l'audio et des images vidéo et commencer à lire les données audio et vidéo décodées en les synchronisant. En général, le navigateur commence par afficher l'audio et la vidéo avant même que la ressource n'ait été téléchargée, car les ressources vidéo sont généralement volumineuses et prennent du temps à télécharger. Du coup, à mesure que le navigateur web affiche la vidéo décodée, il peut en parallèle continuer à télécharger le reste de la ressource vidéo, décoder ces images, les placer en mémoire tampon pour la lecture puis les afficher au moment approprié. Cette méthode est celle du "téléchargement progressif".

Si aucun attribut @autoplay n'est défi ni pour l'élément <video> et qu'aucune image @poster ne soit spécifiée, le navigateur n'affiche que la première image de la ressource vidéo. Il n'a nul besoin de déclencher immédiatement un téléchargement progressif alors qu'il ne sait même pas où l'utilisateur démarrera la lecture de la vidéo. Le navigateur a simplement besoin de télécharger les propriétés vidéo et les métadonnées requises pour configurer le pipeline de décodage, décoder la première image de la vidéo et l'afficher. Il arrête ensuite le téléchargement de la ressource afin de ne pas occuper inutilement la bande passante de l'utilisateur avec des données qu'il pourrait ne pas vouloir regarder. La section des métadonnées d'une ressource vidéo est généralement constituée de quelques kilo-octets à peine.

La bande passante peut encore être optimisée si l'élément <video> possède un attribut @poster. Dans ce cas, le navigateur n'a pas même à se mettre en peine de télécharger les données de la ressource vidéo et peut se contenter d'afficher l'image @poster. Notez que, dans ce cas, le navigateur se trouve en manque d'informations : il n'a pu récupérer aucune métadonnée concernant la ressource vidéo. En particulier, il ne peut déterminer la durée de la vidéo ni même potentiellement savoir s'il sera capable ou non de la décoder. La plupart des navigateurs d'ordinateurs
de bureau ou d'ordinateurs portables entreprennent donc malgré tout de
télécharger la configuration et la première image de la vidéo, alors que sur les périphériques mobiles, ils évitent toute surcharge de la bande passante.

En tant que développeur web, il se peut que vous sachiez mieux que le navigateur web lui-même si l'utilisation de la bande passante est acceptable ou non pour vos utilisateurs. Cette question se pose aussi parce qu'un téléchargement différé des données vidéo implique un délai pour la lecture. Certains développeurs web peuvent ne pas souhaiter que leurs utilisateurs attendent que le pipeline de décodage soit configuré.

L'attribut @preload donne ainsi à l'auteur de la page web la possibilité d'indiquer explicitement le moyen de contrôler le comportement du navigateur web avec les éléments <video>.

L'attribut @preload peut prendre les valeurs none, metadata ou auto.

Listing 2.12 : Vidéo Ogg avec un attribut @preload paramétré avec la valeur none

<video src="HelloWorld.ogv" poster="HelloWorld.png" preload="none" controls>
</video>


Vous pouvez choisir none si vous ne pensez pas que l'utilisateur lira la ressource et que vous souhaitiez minimiser l'usage de la bande passante. Le cas de figure typique est celui d'une page web qui contient de nombreux éléments vidéo (comme une galerie de vidéos) : l'élément <video> possède une image @poster et le navigateur n'a pas à décoder la première image de la vidéo pour la représenter. Dans une galerie vidéo, la probabilité qu'un utilisateur choisisse de lire toutes les vidéos est assez faible. Il est donc de bon usage de définir l'attribut @preload avec la
valeur none pour éviter de gaspiller de la bande passante, en acceptant qu'un délai apparaisse quand une vidéo est sélectionnée pour être lue. Vous acceptez alors aussi que certaines métadonnées ne soient pas disponibles pour la vidéo et ne puissent être affichées par le navigateur, comme les informations de durée de la vidéo.

Listing 2.13 : Vidéo MPEG-4 avec un attribut @preload paramétré avec la valeur metadata

<video src="HelloWorld.mp4" poster="HelloWorld.png" preload="metadata" controls>
</video>


Vous choisirez metadata dans les cas où vous aurez besoin des métadonnées et peut-être de la première image de la vidéo, mais où vous ne souhaiterez pas que le navigateur entame un téléchargement progressif. Ce mode peut aussi convenir pour une galerie vidéo. Par exemple, vous pouvez choisir none lorsque vous proposez votre page web sur un périphérique mobile ou une connexion à bas débit et metadata pour les connexions à haut débit. Il peut aussi être utile de choisir metadata si vous revenez à une page avec une unique vidéo qu'un utilisateur a déjà visitée précédemment, car vous pourrez sans doute considérer que l'utilisateur ne la regardera pas à nouveau, mais souhaiter néanmoins que les métadonnées soient affichées. Le mode de préchargement par défaut est metadata.


Listing 2.14 : Vidéo WebM avec l?attribut @preload paramétré avec la valeur auto

<video src="HelloWorld.webm" poster="HelloWorld.png" preload="auto" controls></video>


Vous choisirez auto lorsque vous souhaiterez encourager le navigateur à démarrer le téléchargement de la ressource entière, autrement dit à réaliser un téléchargement progressif même si la ressource vidéo n'est pas configurée avec l'attribut @autoplay. Le navigateur concerné pourrait ne pas souhaiter le faire, par exemple s'il était exécuté sur un périphérique mobile, mais vous disposerez ainsi d'un moyen de lui signaler que votre serveur ne rencontrera pas de problème et que vous préférez améliorer l'affichage du point de vue de l'utilisateur en réduisant autant que possible le délai de lecture.

La Figure 2.10 montre le résultat des différentes valeurs de @preload dans Firefox, qui affiche également les plages d'octets téléchargées. Il révèle en particulier que pour none, aucune donnée vidéo n'est téléchargée.

figure 2.10 - un élément avec l'attribut @preload et les valeurs none, metadata
Figure 2.10 - Un élément avec l'attribut @preload et les valeurs none, metadata et auto dans Firefox. © Pearson



Vous remarquerez que nous avons placé la même ressource vidéo paramétrée avec trois stratégies de chargement distinctes dans l'exemple de la Figure 2.10. Ce procédé déroute plusieurs des navigateurs et perturbe leurs performances voire les fait carrément planter, aussi n'essayez pas de mélanger les valeurs de @preload pour la même ressource sur la même page web.

La prise en charge de @preload est assurée dans Firefox et Safari : none ne charge rien, tandis que metadata et auto configurent l'élément vidéo avec ses métadonnées et le pipeline de décodage, ainsi que la première image de la vidéo comme image de poster. Chrome, Opera et Internet Explorer ne semblent pas encore prendre en charge l'attribut et l'ignorent.

Il est recommandé de ne pas interférer avec le comportement de mise en mémoire tampon par défaut du navigateur et d'utiliser l'attribut @preload.