.

youtube plus lent sur firefox

Depuis quelques jours les articles fleurissent autour du tweet de Chris Peterson, technical program manager de Mozilla, annonçant que le chargement de la page YouTube est 5 fois plus lent dans Firefox et Edge que dans Chrome. Dans cet article, nous vous alertons sur les défauts de méthodologie dans les mesures de performance et en profitons pour prendre du recul sur la question sous-jacente des standards du web.

Comment mesurer efficacement la web performance ?

Le 24 juillet dernier Chris Peterson, technical program manager de Mozilla, écrivait sur twitter :

Cela proviendrait de « la refonte de Polymer (une bibliothèque JavaScript en Open Source) de YouTube [qui] repose sur l'API obsolète DOM v0 de Shadow ». Cette API se trouverait uniquement dans Chrome, et le temps de chargement d'une page YouTube impacterait d'1 à 5 secondes selon qu'on utilise Chrome ou bien Firefox et Edge.

Point d’alerte sur les mesures des performances

Si nous nous attardons sur sa méthode de mesure décrite un peu plus bas dans ses tweets, nous constatons que les tests n’ont vraiment pas été réalisés dans les règles de l’art :

« La "différence de 5x" que j'ai mesurée (5 secondes contre 1 seconde) était le temps nécessaire pour remplacer les boîtes d'espace fictives grises par du contenu (commentaires et miniatures) sur mes ordinateurs portables Mac et Windows et sur Internet à 200 Mbps hier. Vos résultats peuvent varier en fonction de la vitesse de votre ordinateur et de votre réseau. »

Pour obtenir des résultats plus fiables, Chris n’aurait pas dû réaliser ces tests sur son poste. Il aurait fallu utiliser :

  • un outil de Synthetic Monitoring : les tests sont exécutés sur des serveurs depuis des datacenters utilisant une connexion bridée pour simuler les conditions qu’un utilisateur moyen peut rencontrer. Les pages web sont réellement chargées depuis un navigateur web afin de collecter des mesures de performance correspondant à la réalité de l’expérience utilisateur.
  • ou mieux encore utiliser un outil de Real User Monitoring (RUM) : les mesures ne sont plus effectuées à un instant T mais en continu. Un code JavaScript injecté dans chaque page web permet de mesurer les temps de chargement de la page pour chaque requête.

Pour en savoir plus sur le Synthetic Monitoring vs le Real User Monitoring >>


Lancement du test sur un outil de Synthetic Monitoring : Webpagetest

Résultats Chrome Résultats Firefox
Conditions du test URL: https://www.youtube.com
From: Paris
Navigator: Chrome
Connexion: Average French DSL
Run: 3
URL: https://www.youtube.com
From: Paris
Navigator: Firefox
Connexion: Average French DSL
Run: 3
Liens des tests Test Chrome Test Firefox
Performances Load time: 2,831s
First Byte: 0,359s
Start Render: 1,300s
Speed Index: 2136
Load time: 4,082s
First Byte: 0,548s
Start Render: 2,500s
Speed Index: 3165

Ces premiers résultats (qui mériteraient d’être confirmé par une autre batterie de tests), montrent qu’en effet Youtube se chargerait bien moins vite sur Firefox que sur Chrome.


Mais ce débat incite malgré tout à prendre un peu de recul sur l’utilisation des API qui sont non-standards.

Le risque d’utiliser des API non standards

Qu’est-ce qu’un standard et comment naît-il ?

Les standards web sont une base commune qui assure la cohérence du code qui constitue une page Web et même l’ensemble de l’internet.
Ces standards sont définis par les organisations de normalisation, comme le W3C ou l’IETF. Ces normes et standards du web assurent la compatibilité, mais aussi les évolutions du web.

La naissance d’un standard passe en théorie par plusieurs étapes :

  • La création d’une spécification
  • Le développement
  • Une répétition de passages en revue par la communauté Internet
  • Des révisions suite aux retours d'expériences
  • Elle est ensuite adoptée comme standard par l'instance appropriée et fait l’objet d’une RFC.

Mais la réalité n’est pas si simple en raison de la difficulté à créer des spécifications de haute qualité technique, la nécessité de tenir compte des intérêts de toutes les parties concernées, l'importance d'obtenir un large consensus de la communauté et la difficulté d'évaluer l'utilité d'une spécification particulière pour la communauté Internet.

Souvent, les standards naissent d’initiatives privées. Google est par exemple très actif en proposition puisqu’ils disposent de nombreuses données.

C’est d’ailleurs ce qui a en partie donné naissance à HTTP/2 :
Google a dévoilé en 2009 le protocole SPDY : un protocole permettant de réduire la durée de chargement des pages Web en ordonnant les fichiers selon leur priorité et en optimisant leur transfert, de façon à ce que ces fichiers soient transmis en une seule connexion (on parle de multiplexage). SPDY a été ensuite utilisé comme base pour l’HTTP/2.

Il en est de même pour Quic. Né d’une initiative Google, il a ensuite été largement amélioré par la communauté et a été standardisé par l’IETF. Nous parlons désormais de gQuic pour l’implémentation initiale de Google et de Quic pour la version améliorée par la communauté.

Mais il arrive que certaines de ces initiatives ne soient pas standardisées. C’est notamment le cas de WebP, un format d'image conçu par Chrome qui offre une meilleure compression sans perte de qualité. WebP n’est pourtant pas devenu un standard.
Nous pourrions aussi citer l’exemple de AMP (Accelerated Mobile Pages), encore une fois imaginée par Google, qui est largement remis en cause par la communauté et qui n’aboutit pas non plus à une standardisation.

Les standards cohabitent ainsi avec des évolutions propres aux navigateurs, ce qui amène à des divergences, notamment de performance, comme dans le cas de Youtube dont on parle ci-dessus.

« C’est bien qu’il y ait des initiatives pour faire évoluer les choses. Mais c’est dommage qu’il y ait cette divergence et que les évolutions proviennent principalement des initiatives privées. On en vient à améliorer les performances pour un navigateur donné. Cela ne me semble pas être une bonne chose. D’autant plus que, tout le monde n’a pas le même poids (Microsoft vs Apple ou Google par exemple). Microsoft a poussé des formats d’image qui n’ont jamais pris. Idéalement, il faudrait que ces initiatives naissent au sein des organismes de standardisation. » Stéphane Rios, CEO de Fasterize.

Restez informé.e de notre actualité, inscrivez-vous à notre Newsletter :