- Même un seul embed YouTube `` sur une page vide déclenche 32 requêtes et 1,3 Mo de données transférées, ce qui est excessif pour une petite interface vidéo
- Si l’on ajoute plusieurs vidéos, les ressources ne sont pas mutualisées et le poids augmente linéairement ; selon les mesures de Zach Leatherman, on monte à 2,4 Mo pour 2 embeds et 3,6 Mo pour 3 embeds
- Les premiers éléments visibles se limitent à l’image d’aperçu, au titre et à un gros bouton de lecture ; un Web Component comme `` peut reproduire la même expérience de façon beaucoup plus légère
lite-youtube-embed tourne autour de 100 Ko et mutualise les ressources entre plusieurs embeds, ce qui améliore vitesse et efficacité sans perte fonctionnelle- Comme les embeds YouTube sont omniprésents, réduire des mégaoctets de données par embed constitue une optimisation concrète qui baisse aussi la consommation électrique et les émissions carbone
Le coût de l’embed `` par défaut
- Dans le menu de partage de YouTube, l’option
Embed fournit un HTML basé sur ``
- Le code par défaut n’inclut pas
loading="lazy", si bien que même les vidéos hors écran peuvent être chargées immédiatement
- Rien qu’en ajoutant le chargement différé à l’iframe par défaut, YouTube pourrait améliorer les performances immédiatement
- Pour rendre l’iframe réactive tout en conservant son ratio d’origine, on peut cibler directement l’iframe de l’embed YouTube en CSS
iframe[src^="https://www.youtube.com/embed/";] {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16 / 9;
}
Mesures réelles et augmentation linéaire
- Même en plaçant un seul embed YouTube sur une page vide, le coût de chargement reste important
-
32 requêtes
- 1,3 Mo de données transférées
- 2,76 secondes de chargement sur le Wi‑Fi de l’auteur
- Zach Leatherman note que le poids augmente linéairement à mesure que le nombre d’embeds croît, faute de mutualisation des ressources
- 2 embeds : 2,4 Mo
- 3 embeds : 3,6 Mo
- Il semble qu’aujourd’hui la taille soit encore plus élevée qu’à l’époque de la vérification de Zach
L’interface visible au premier affichage est simple
- Dans un embed YouTube, les éléments auxquels l’utilisateur est d’abord confronté sont limités
- l’image d’aperçu de la vidéo
- le titre de la vidéo
- un gros bouton de lecture qui lance la vidéo au clic
- Cette interface et ce comportement peuvent être reproduits sans charger d’emblée toutes les ressources du lecteur YouTube complet
- Il est difficile de juger l’affirmation selon laquelle un embed plus léger réduirait l’engagement tant que la méthodologie et les données ne sont pas publiées
- Par le passé, lorsqu’un ingénieur de YouTube a testé une page vidéo plus légère, le temps de chargement moyen a au contraire augmenté
- La page plus légère est aussi parvenue à des utilisateurs sur appareils peu puissants et connexions Internet lentes
- L’usage de ces nouveaux utilisateurs rendus accessibles a pu dégrader l’indicateur moyen de temps de chargement
- Se limiter au temps de chargement moyen peut masquer les gains réels de vitesse selon les profils d’utilisateurs
Alternative : le Web Component ``
- lite-youtube-embed, créé par Paul Irish, figure reconnue de la performance chez Google, est un Web Component qui reproduit plus légèrement l’expérience de l’embed par défaut
- La description du projet indique qu’il effectue ce rendu comme un embed réel tout en étant environ 224 fois plus rapide
- L’expérience utilisateur est presque identique à celle de l’embed YouTube standard
- affichage de l’image d’aperçu
- affichage du titre
- affichage d’un gros bouton de lecture
- lecture de la vidéo au clic
- La différence tient à la consommation de ressources et à la façon dont elles sont mutualisées
- embed YouTube par défaut : environ 1,3 Mo
- `` : environ 100 Ko
- mutualisation possible des ressources entre plusieurs embeds
- vitesse, efficacité et protection de la vie privée de base, sans perte fonctionnelle
Mode d’utilisation et implémentation associée
- Le principe consiste à enregistrer le Web Component en JavaScript puis à utiliser l’élément ``
- Installation via npm, copie directe ou lien CDN : les trois approches sont possibles
import "https://esm.sh/lite-youtube-embed";;
- La méthode recommandée dans le README consiste à placer d’abord le HTML, puis à charger le script en asynchrone afin d’appliquer une amélioration progressive
- On peut mettre
background-image directement dans le HTML afin que l’affichage reste correct avant même le chargement du JavaScript
[Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)
- Il existe aussi des implémentations et alternatives liées
2 commentaires
lite-youtube-embed - intégration YouTube plus rapide
Avis sur Hacker News
Sur une plateforme de forum communautaire, on détecte les embeds YouTube et on les remplace par des vignettes proxy qui ne se chargent pas avant un clic.
Ce n’est pas parce qu’une personne dans un fil partage une vidéo YouTube que toutes celles qui ouvrent la page doivent télécharger plus de 1 Mo de JavaScript et se faire tracer leur IP par Google.
Le tracking ne me préoccupe pas beaucoup, donc j’utilise simplement les vignettes fournies par YouTube.
Le lecteur SoundCloud est lui aussi extrêmement lourd.
Si on hotlinke les vignettes, Google peut aussi tracer par ce biais.
L’auteur dit ne pas croire aux éléments montrant qu’une version plus légère ferait baisser l’engagement, mais je pense que c’est tout à fait possible.
La démo du projet lite-youtube-embed recommandé contient à la fois le lecteur léger et le lecteur normal, et la version légère met visiblement plus longtemps à lancer la vidéo.
Chaque milliseconde de temps de chargement supplémentaire réduit l’engagement, et ici l’écart semble être d’au moins plusieurs centaines de millisecondes.
https://paulirish.github.io/lite-youtube-embed/
L’argument selon lequel chaque milliseconde compte s’applique aussi aux pages web. Si l’utilisateur quitte la page, il n’ira même pas jusqu’à la vidéo.
Et il peut aussi être acceptable que l’utilisateur ne veuille pas regarder la vidéo. Personnellement, j’aime pouvoir éviter une vidéo lorsqu’une page web en propose un résumé.
La refonte desktop de YouTube m’agace aussi : l’écran consacre trop de place à promouvoir d’autres vidéos plutôt que celle que je suis venu voir. J’aimerais moins de distractions.
Pour reprendre l’image des feux tricolores, je préfère que le feu auquel j’arrive soit vert plutôt que tous les feux soient brièvement rouges.
Quand on regarde le comportement réel des grandes entreprises, il est évident qu’elles ne s’en soucient pas, et si ce n’est pas important pour elles, il n’y a pas de raison que nous optimisions à leur place.
Dans ce cas d’usage, ce n’est pas un gros problème, mais il faut se soucier des performances dans le reste de la stack.
Je ne sais pas comment on en est arrivé à une telle régression, et Google semble progressivement casser des choses qui fonctionnaient parfaitement bien.
Cela peut dépendre de l’environnement : Firefox, un portable i7-1185G7 d’environ deux ans, Windows 11, Edge en mode 32 bits qui est constamment en cours de mise à jour et une machine qui n’a pas été redémarrée depuis plusieurs semaines.
Ce qui donne surtout une impression de lenteur, c’est l’indicateur de chargement qui tourne. C’est comme s’il annonçait lui-même qu’il est lent.
Le délai entre le clic et la lecture a sûrement un effet, mais pour le mesurer correctement, il faudrait un acteur de la taille de YouTube.
À propos de la rumeur selon laquelle un embed plus léger réduirait l’engagement et de lite-youtube-embed proposé, les utilisateurs peuvent percevoir un lecteur qui a simplement une apparence ou un comportement un peu différent comme quelque chose d’inconnu et de peu fiable.
Dans la démo de lite-youtube-embed, même si le titre s’affiche, il n’y a pas de lien vers la vraie page YouTube, ce qui donne même une impression hostile, comme si l’on empêchait d’accéder au « contenu » d’origine.
Bien sûr, cette fonctionnalité pourrait être ajoutée facilement, mais cela révèle un problème plus large.
Je lance très rarement des vidéos intégrées, mais si je le fais, l’expérience YouTube normale me suffit. Si on l’enveloppe dans une autre couche inconnue, j’ai moins de chances de cliquer.
La formule de l’article selon laquelle « rien n’est sacrifié » est un exemple de développeur qui croit savoir comment les utilisateurs utilisent un logiciel. En réalité, ce ne sont toujours que des suppositions.
J’aimerais qu’il y ait moins de vidéos, moins de dépendance à Google partout et moins de gros blocs de JavaScript. Pour un meilleur Web, j’aimerais qu’on n’intègre pas des vidéos YouTube n’importe où.
https://paulirish.github.io/lite-youtube-embed/
Maintenant que je le sais, j’aimerais que ce bouton existe aussi dans ces lecteurs légers. Cela dit, cette implémentation ne bloque pas complètement les moyens faciles d’obtenir le lien.
On peut y accéder en lançant la vidéo, mais cela va à l’encontre du but recherché. Je ne veux pas lancer la vidéo, ni attendre qu’elle se charge, la mettre en pause puis appuyer sur le bouton d’enregistrement.
Il ne reste plus qu’à empêcher les blogueurs d’utiliser les embeds GitHub Gist
Hugo, et probablement d’autres générateurs de sites statiques, prennent en charge nativement les extraits de code avec coloration syntaxique, et même les sites plus dynamiques peuvent se passer d’une dépendance à un service tiers avec highlight.js
Utiliser une iframe lourde pour un petit extrait de code, c’est vraiment étrange
https://gohugo.io/content-management/syntax-highlighting/
https://highlightjs.org
Même si ça ne me plaît pas, ça n’a pas de sens de les “forcer” à modifier leur site pour qu’il corresponde à mes goûts
Ça a été corrigé en quelques semaines, mais j’ai été surpris que ce soit resté comme ça pendant des années
Si une page peut exploiter une Content Security Policy, il est possible de bloquer les publicités pour réduire le poids total des embeds et améliorer aussi l’expérience utilisateur
Infos associées : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Content-Security-PolicyCela désactive en effet la protection de CSP contre les attaques par injection. Si c’est vraiment nécessaire, il existe des méthodes plus sûres pour autoriser les scripts inline
https://content-security-policy.com/
Il me semble qu’il manque une grosse partie dans l’histoire selon laquelle “des embeds plus légers ont réduit l’engagement”
En principe, si le temps de chargement s’améliore, l’engagement devrait augmenter. Donc si l’engagement baisse avec un embed léger, cela signifie qu’une fonctionnalité ou un comportement a été sacrifié
Or l’article dit qu’il n’y a eu aucun sacrifice, donc il manque quelque chose dans le récit
Il pourrait se passer la même chose ici. Grâce à un embed plus léger, beaucoup de personnes ont peut-être pu charger la vidéo pour la première fois, mais ont abandonné au moment de la lecture à cause d’un appareil ou d’une connexion trop lente
Dans ce cas, des personnes qui ne chargeaient auparavant jamais complètement le player, et ne laissaient donc aucune donnée, apparaissent maintenant comme faisant augmenter le taux “d’abandon pendant le visionnage”
Les utilisateurs ont des attentes et des tolérances différentes en matière de temps de chargement selon l’objet concerné, et la page et la vidéo qu’elle contient sont deux objets distincts
Le temps de chargement de toute la page n’est pas toujours lié au temps de chargement de l’embed, et le chargement global de la page peut aussi masquer le temps de chargement du contenu
La métrique la plus importante n’est peut-être pas le temps de chargement de l’embed, mais le délai entre le clic et le début de la lecture
Comme solution côté utilisateur pour les utilisateurs d’uBlock, on peut utiliser des filtres click2load
Attention toutefois, Chrome est en train de passer à Manifest V3, donc cela pourrait ne pas fonctionner. Les filtres de yokoffing/filterlists peuvent servir de référence
https://raw.githubusercontent.com/yokoffing/filterlists/main...
C’est le créateur de Betterfox, et il y a aussi d’autres filtres utiles sur son GitHub
Ce que je veux, c’est simplement un lien ordinaire ; j’avais donc écrit autrefois un petit userscript qui remplaçait les iframes YouTube des pages par des liens
Pour une implémentation aussi simple, ça fonctionne étonnamment bien. Il trouve les iframes
youtube.com/embedetyoutube-nocookie.com/embed, les remplace par des lienswatch?v=, conserve aussi les timestamps, et peut ajouter une vignette si on le souhaiteLe passage disant que “plus le nombre d’embeds augmente, plus le poids augmente linéairement. Deux font 2,4 Mo, trois font 3,6 Mo” est étrange
Je me demande pourquoi ces ressources ne sont pas récupérées depuis le cache. Si elles sont toutes chargées depuis
www.youtube.com, il me semble que, selon la politique de même origine, les ressources mises en cache devraient pouvoir être utiliséesLe meilleur passage de l’article, à mon avis, est celui où le passage à une page plus légère a finalement fait augmenter le temps moyen de chargement des pages
En y regardant de plus près, des utilisateurs avec des appareils bas de gamme et une connexion Internet lente ont pu utiliser YouTube réellement pour la première fois, et comme ils l’utilisaient beaucoup, la moyenne semblait ralentir
En réalité, la vitesse d’utilisation avait relativement augmenté pour tout le monde, et j’ai trouvé frappant que la métrique de vitesse moyenne de chargement des pages se révèle finalement être un leurre sans grande signification
J’avais autrefois créé une extension Firefox qui remplaçait tous les embeds YouTube par des vignettes et ouvrait YouTube au clic
À l’origine, je l’avais faite parce que les téléphones n’avaient pas Flash alors que les embeds Flash étaient courants, puis je l’ai étendue plus tard pour gérer aussi les embeds iframe
Dans la plupart des cas, ouvrir le site ou l’app YouTube complète offrait aussi une meilleure expérience utilisateur qu’une petite fenêtre d’embed
Je l’avais pourtant écrite pour la nouvelle API d’extension de haut niveau de l’époque, mais la compatibilité entre versions du navigateur n’a pas suivi comme je l’espérais ; ça m’a agacé, et je ne l’ai donc pas portée vers WebExtension. Cet article me donne envie de la porter à nouveau