Intégration vidéo : pourquoi réfléchir avant d'utiliser un player YouTube sur son site web

Rassurez-vous : nous n’allons pas parler respect de la vie privée, bien que la tentation soit forte (notre pôle RGPD Temesis est plus qualifié que moi pour intervenir sur cette problématique). Simplement, avant de nous rendre chez YouTube, commençons par parler de l’impact de YouTube vis-à-vis de nos propres services numériques.

Il faut savoir s’intégrer

Il est aujourd’hui très facile d’injecter, au sein même de n’importe quelle page web, un lecteur vidéo porté par YouTube. On parle alors d’intégration tierce.

En clair, il suffit de copier-coller quelques caractères dans le code source d’un service numérique afin que la vidéo que nous avons mise en ligne ou sélectionnée au préalable puisse apparaitre où nous le décidons. Une fonctionnalité 100% gratuite. Tout comme l’avait été l’intégration de Google Maps avant de devenir payante du jour au lendemain. Hum.

Certains arguments en faveur de YouTube sont plus techniques (mais séduisants) :

• Il permet de proposer plusieurs définitions d’images d’une même vidéo, dans des formats modernes (WebM, H264) et donc de satisfaire un plus large panel d’utilisateurs (attentes, réseau ou encore qualité d’écran variables).
• Il permet de délivrer de la vidéo au plus proche des utilisateurs (proximité géographique de ses centres de données).

Cet éloge fait, déconstruisons tout cela, chiffres à l’appui.

Un utilisateur, des expériences

J’ai créé un document HTML (une page web) sur un serveur local avec pour seul contenu le code d’intégration de cette vidéo hébergée sur Youtube. Voici le contexte utilisateur associé à cette expérience :

• J’utilise Firefox Developer Edition (version 103).
• Je simule une sortie d’écran à 1366 x 768 pixels.
• Je n’ai aucun bloqueur de publicités actif.

Et le rendu visuel sommaire, où le lecteur apparait dans le coin supérieur gauche de l’écran :

J’ai ensuite inspecté la page avec les outils de développement web intégrés à mon navigateur, pour y relever des informations croustillantes !

(psst : apprenez à en faire autant, formez-vous à mes côtés)

Performance web : et si ce n’était pas le domaine de YouTube ?

Première claque, l’intégration YouTube appelle… 9 domaines différents.
En voici le détail :

• fonts.gstatic.com
• googleads.g.doubleclick.net
• i.ytimg.com
• jnn-pa.googleapis.com
• play.google.com
• static.doubleclick.net
• www.google.com
• www.youtube.com
• yt3.ggpht.com

Sur le Web, il faut établir une passerelle avec chaque domaine sollicité avant de pouvoir échanger avec (résolution DNS, connexion, établissement liaison TLS). La multiplication de ces poignées de mains retarde la disponibilité d’une page et consomme plus d’énergie un peu partout (chez les 3 tiers du Numérique, à savoir équipements utilisateurs, infrastructures réseaux et centres de données). Écoconception numérique ou pas, mieux vaut donc éviter de s’éparpiller auprès d’un nombre conséquent d’intermédiaires.

Une charge data virale forte

Et si l’on y réfléchissait à deux fois avant d’utiliser tout et n’importe quoi dans une page web ? Une intégration tierce YouTube dans une page web, c’est :

• Au moins 20 requêtes.
• 2,9 Mo décodés.
• 880 Ko transférés.

Guide de survie de ces termes techniques :

• Les requêtes négocient l’échange de ressources entre clients et serveurs : un document HTML, un script JavaScript, une image, une fonte, etc.
• Les données transférées comprennent le poids des ressources en phase de transit à travers le réseau et des en-têtes de réponse HTTP associés.
• Les données décodées correspondent au poids des ressources en phase de stockage.

Maintenant que vous avez quelques clefs de déchiffrage, voici des détails :

• JavaScript

  • 7 requêtes.

  • 2,43 Mo décodés.

  • 726,82 Ko transférés.

  • Il s’agit de la plus grosse part de ressources du player YouTube, dont une base applicative complexe notamment constituée :

    • D’un fichier base.js de 1,94 Mo décodé, 566,01 Ko transférés.
    • D’un fichier www-embed-player.js de 306,86 Ko décodés, 95,41 Ko transférés.
    • D’un fichier remote.js de 119,41 Ko décodés, 37,63 Ko transférés.

• CSS

  • 1 requête, www-player.css, dont le poids laisse songeur (340,37 Ko décodés / 47,50 Ko transférés). Pour comparaison, voici ce qui est utilisé sur le blog Temesis pour mettre en forme l’article que vous avez sous les yeux : 25,05 Ko décodés (7,36 % de ce dont a besoin YouTube pour un simple lecteur) ou encore 7,17 Ko transférés.

• Police d’écriture (Roboto)

  • S’agissant de la police par défaut sur Android, et au regard des parts de marché de l’OS, les utilisateurs mobile et tablette ont de grandes chances de la télécharger inutilement sur leur terminal.

• Images

  • Au moins 2 requêtes, dont le poids varie en fonction de la source. La première est une image de prévisualisation de la vidéo ; celle-ci informe l’utilisateur du contenu et peut lui permettre de décider en son âme et conscience s’il souhaite lancer ou non la lecture (ce qui est plutôt positif). La seconde image est celle du profil du propriétaire de la vidéo (le compte qui l’a mise en ligne sur la plateforme). Bien anecdotique !

À cela s’ajoute un zest de trafic autour de l’étude du comportement utilisateur. YouTube, c’est Google, n’oubliez pas.

Il me semble opportun de rappeler qu’à ce stade où la lecture n’a pas été lancée, la vidéo doit encore être téléchargée par le navigateur. J’ajoute aussi qu’à ce budget s’ajoutent d’autres ressources utiles à la construction d’une page web réelle (votre contenu HTML, vos feuilles de style CSS et script JavaScript, vos médias). Plutôt handicapant pour la suite.

Cachez-vous, j’arrive !

Le bon côté des choses, c’est que YouTube a une politique de mise en cache assez forte côté client puisqu’il invite les navigateurs à stocker son lecteur jusqu’à 1 an sur le terminal de l’utilisateur (31536000 secondes pour être précis). Ainsi, quand l’utilisateur revient sur la page, il n’est pas nécessaire pour son navigateur de tout redemander au réseau.

Il y a un mais, encore. Une fois n’est pas coutume : on ne parle que du lecteur, pas de la vidéo. J’irai même plus loin : on ne parle que de ce lecteur.

Chez YouTube, on ne partage pas

Une information qui mériterait presque un article à part entière : chaque intégration YouTube est indépendante des autres.

Si je décide de dupliquer mon lecteur YouTube sur ma page de test…

…L’on pourrait presque s’attendre à ce qu’il y ait mutualisation des ressources. S’agissant cependant d’intégrations (on parle d’iframe), chaque lecteur évolue dans son propre contexte, avec ses propres dépendances.

Et c’est un problème (dont peu de monde semble avoir pris connaissance).

Si pour un lecteur, j’ai besoin de :

• 20 requêtes.
• 2,9 Mo décodés.
• 880 Ko transférés.

Cela signifie que :

• 2 lecteurs = 40 requêtes, 5,8 Mo décodés, 1.72 Mo transférés.
• 4 lecteurs = 80 requêtes, 11,6 Mo décodés, 3,44 Mo transférés.
• Etc.

Et nous n’avons ENCORE chargé aucune vidéo, uniquement des lecteurs. Autant dire que cela commence à coûter cher côté environnement et expérience utilisateur.

Car, par défaut, et à moins de court-circuiter le chargement des iframes, ce qui exige une expertise technique, les lecteurs se chargent à l’atterrissage sur la page, au détriment des temps de chargement et de prise en main du service numérique (ces indicateurs dont raffole Google en tant que moteur de recherche - en anglais).

Ce qui est terrible, c’est que pour se conformer aux obligations relatives au dépôt de cookies tiers (RGPD), il est monnaie courante de désactiver ces intégrations jusqu’à obtention d’un consentement utilisateur. Sauf qu’empêcher un dépôt de cookies tiers est une tout autre affaire. Les lecteurs bloqués ne le sont parfois que sur le plan visuel, après avoir téléchargé toutes leurs ressources. C’est par exemple le comportement de la bibliothèque tarteaucitron.js que je rencontre beaucoup en audit RGESN.

Que se passe-t-il quand on lance une vidéo YouTube depuis une intégration ?

Beaucoup de choses !

L’analyse se complique cependant ; trop de variables entrent en ligne de compte pour faire jaillir des chiffres représentatifs ou vérifiables.

Quelques certitudes :

• La vidéo est transmise petit bout par petit bout…
• … Et YouTube en refuse explicitement la mise en cache côté client. Ce qui peut s’entendre dans la mesure où la plateforme doit pouvoir donner un contrôle absolu à ceux qui diffusent du contenu (mise à jour, suppression). Eh oui : si quelque chose bouge, il faut que cela se répercute partout sur le Web.
• Plusieurs sprites d’images, permettant de prévisualiser la vidéo à un instant T au survol de sa timeline, peuvent être chargées.
• Différents journaux et statistiques sont alimentés en contenu.
• La première fois que l’utilisateur met la vidéo en pause, 12 vignettes sont téléchargées pour le carrousel “Plus de vidéos” (4 écrans de 3 images). Dans notre exemple, on parle ainsi de 332,83 Ko décodés / 217,50 Ko transférés qui ne sont pas directement utile à la vidéo.

YouTube mise ainsi beaucoup sur l’expérience utilisateur. Au point d’en faire des tonnes (de CO2).

Une alternative raisonnable, à défaut de se passer de la vidéo

Le saviez-vous ?

HTML5 permet d’intégrer nativement un lecteur vidéo sur une page web, sans JavaScript ni CSS, avec la possibilité :

• D’y préciser plusieurs sources.
• De ne pas précharger la vidéo avant intérêt manifeste de l’utilisateur.
• De fournir une image de prévisualisation.

Le tout, sans ce côté “J’en fais trop” de YouTube.

Les bénéfices ?

• Vos utilisateurs accèdent plus vite à vos pages et à vos vidéos, tout en consommant moins de ressources (à condition d’avoir optimisé vos médias, cela va de soi).
• Vous choisissez les contenus vers lesquels vous souhaitez (ré)orienter vos visiteurs (là où ce contenu leur / vous est imposé avec YouTube).
• Vous n’avez pas à vous préoccuper d’une demande de consentement liée à l’usage d’un service tiers.

Si pertinent, un Réseau de diffusion de contenu (ou CDN, pour Content Delivery Network) peut être exploité pour garantir que les utilisateurs soient servis au plus proche de leur demande.

Plus efficiente.
Plus résiliente.
Plus éthique.

Pourquoi ne pas considérer cette approche à sa juste valeur ?

Rappel du sommaire de l’étude

1. YouTube est-il le roi de l’écoconception numérique ?
2. Intégration vidéo : pourquoi réfléchir avant d’utiliser un player YouTube sur son site web (cet article)
3. Youtube.com : un modèle de performance web environnementale ?