Wikipedia est régulièrement en tête du classement webperf du JDN toutes catégories confondues. Pour comprendre comment ce site travaille sur ses temps de chargement, nous sommes allés à la rencontre de Gilles Dubuc, Senior Software Engineer à la Fondation Wikimedia. Cet expert webperf nous livre son regard sur le sujet, et ses questionnements sur la relativité des indicateurs en vigueur parmi les pros du secteur. Entretien.
Qui êtes-vous Gilles Dubuc ?
J’ai fait du développement web pendant plus de 10 ans, j’ai travaillé entre autres pour DeviantArt, et je travaille à la Fondation Wikimedia depuis 2014. Wikipedia, c’est 16 milliards de pages vues chaque mois, 350 employés dont un peu plus d’un tiers d’ingénieurs - ce qui reste très modeste par rapport au trafic du site ! J’ai rejoint la fondation dans le cadre d’un projet de fonctionnalité qui permet d’ouvrir les images rapidement dans les articles Wikipedia pour les agrandir.
Cette fonctionnalité a fait émerger des enjeux : comment préserver les temps de chargement avec une image de qualité ? Quelle taille d’image servir à quel moment ? Doit-on charger le JS en avance ou quand la personne interagit avec la fonctionnalité ? Ce sont toutes ces questions qui ont naturellement fait de la performance web un sujet important au moment du développement de cette fonctionnalité, et qui ont fait que je me suis intéressé à la webperf dans son ensemble sur Wikipedia.
Comment la webperf s’est-elle installée parmi les priorités de Wikipedia ?
Nous avions la volonté de monter une équipe dédiée à la webperf. Depuis 4 ans, 5 personnes travaillent à temps plein sur le sujet. Même si chacun a ses affinités, nous travaillons sur tous les aspects : front-end et back-end, télémétrie, tests d’intégration continue, veille de la performance du site.
Il y a aussi un double enjeu : nous devons travailler la webperf à la fois pour les lecteur.rice.s et pour les contributeur.rice.s.
Pour les lecteur.rice.s nous avons notre propre CDN composé de 5 datacenters dans le monde pour que le contenu soit servi depuis le point le plus proche pour chaque visiteur.se.
Plus récemment, notre nouveau datacenter à Singapour nous a permis d’améliorer notre Time To First Byte de 30 % pour les internautes qui se connectent depuis l’Asie.
Pour les contributeur.rice.s en revanche, le datacenter est pour l’instant uniquement aux USA, une limitation que nous allons résoudre à moyen terme.
Notre socle technique a 15 ans, il est totalement open source et nous y apportons des évolutions au fur et à mesure tout en maintenant l’existant, avec de fortes contraintes budgétaires, car la Fondation Wikimedia est un organisme à but non lucratif qui ne vit que des dons.
Nous nous appuyons sur notre propre infrastructure physique et nous travaillons actuellement sur une nouvelle architecture basée sur Kubernetes qui nous apporte les avantages du cloud. Les tests auxquels nous procédons pour mesurer la webperf se font sans données utilisateur.rice.s.
Quels indicateurs webperf suivez-vous ?
Nous effectuons des tests synthétiques à l’aide d’outils tels que WebPageTest et Webpagereplay qui nous permettent de mesurer des indicateurs propres au synthétique, comme le Speed Index. Nous surveillons également les indicateurs RUM collectés directement sur les internautes, tel que le Time To First Byte qui nous permet entre autres de détecter les problèmes de réseau, le First Contentful Paint et le LoadEventEnd.
Ce dernier indicateur est souvent considéré comme archaïque parce qu’il implique que tout le contenu d’une page soit chargé entièrement, y compris ce qui n’est pas visible. Cependant nos recherches nous ont montré qu’il est pour l’instant celui qui a la meilleure corrélation avec la perception des utilisateur.rice.s.
Quand vous développez de nouvelles fonctionnalités, comment intégrez vous la webperf ?
La webperf est au centre de nos priorités et dès que nous lançons une nouveauté, nous faisons de la pédagogie en interne. Nous avons beaucoup travaillé pour ne pas passer pour “la police de la webperf” et inciter à penser performance dès la conception, exactement comme on pense des produits “secure by design”. En effet, respecter les bonnes pratiques webperf engage à faire des choix en termes d’architecture, donc mieux vaut y penser tout en amont plutôt qu’en bout de course au risque de devoir tout refaire.
Notre consigne : rester au moins aussi performant que la version précédente.
Globalement, je peux dire que nous avons la chance de pouvoir expérimenter et adopter de nouvelles technologies plus rapidement que d’autres équipes. On veut aussi participer au futur du web !
A ce propos, comment voyez-vous le futur de la webperf ?
Je fais partie du W3C, et la Fondation Wikimedia va bientôt en devenir membre également. Dans ce cadre, j’ai eu l’occasion de participer à la dernière conférence TPAC à Lyon. Au cours de mes rencontres avec les éditeurs de navigateurs, j’ai constaté qu’ils avaient tendance à imaginer des solutions sans forcément avoir des retours de beaucoup de sites internet au moment de la conception initiale des standards. Ils étaient très curieux de savoir ce qui était le plus utile pour nous en termes de webperf, et ce qui pouvait nous bloquer actuellement.
La Fondation Wikimedia a exprimé des besoins en matière de mesure de webperf qui nécessitent la définition de nouveaux standards. Ainsi, depuis cette année nous participons à des essais avec Chrome (Origin Trials) pour tester de nouvelles fonctionnalités en avance et évaluer leur pertinence. Les tests sont réalisés sur le trafic de Wikipedia, par exemple pour mesurer la réactivité de la page à l’aide d’une API en cours de développement - ce qui est actuellement particulièrement difficile à estimer.
Nous souhaitons par exemple mesurer la performance tout au long de la navigation, et pas seulement au moment du chargement initial, comme le fait actuellement le Time To Interactive.
Par exemple Event Timing va permettre d’évaluer le temps de réaction après avoir cliqué sur un lien, un bouton, un menu… Ce temps de réaction peut affecter l’expérience de navigation et du coup la perception que les internautes auront de la performance du site.
L’UX est vraiment un élément central alors…
Oui ! J’ai participé à un programme de recherche en 2018 avec Télécom ParisTech, pour faire le lien entre la perception de la performance et les données qu’on mesure.
Nous collectons beaucoup de données de navigation, mais en réalité, on ne sait pas hiérarchiser ce qui est important pour les internautes. Nous leur avons donc posé la question ouvertement : “Pensez-vous que la page s’est chargée rapidement ?”, et nous avons observé les réponses dans différents contextes pour voir si ce dernier avait une influence sur la perception de vitesse.
Nous avons notamment découvert que l’état d’esprit au moment de la consultation de la page n’a pas d’influence sur la perception de vitesse. Même en visitant des articles Wikipedia au stade d’ébauche contenant peu d’information, ce qui peut être source de frustration, les réponses des internautes ne changeaient pas. Nous en avons conclu que les facteurs extérieurs avaient peu d'influence sur la perception de vitesse.
Idem lors de la perte de l’équipe de Russie pendant la dernière Coupe du monde de football : le ratio de réponses des utilisateur.rice.s de Wikipedia dans cette zone du monde n’ a pas changé.
L’environnement extérieur n’intervient donc jamais sur la perception de vitesse ?
Si bien sûr. Par exemple, au bureau, les internautes s’adaptent. Il.elle.s ont du matériel moins performant qu’à la maison, des connexions moins rapides, donc leur niveau d’exigence baisse.
Du coup, se pose la question de la pertinence et de l’objectivité des indicateurs : est-ce qu’ils reflètent vraiment les impressions des utilisateur.rice.s ?
Jusqu’ici la plupart des indicateurs qu’on peut mesurer sur les navigateurs ont été créés en fonction de ce qui était facile à exposer. Mais je souhaite que nous puissions évoluer vers des indicateurs qui traduisent ce que l’humain ressent vraiment.
Mais alors, comment faire pour que les indicateurs de performance se rapprochent de l’expérience vécue par un être humain ? Va-t-on s’éloigner du Synthetic Monitoring ?
Pour mesurer la vitesse d’affichage véritable du contenu, entre autres, on se base en effet sur du Synthetic Monitoring. A l’avenir, nous aurons des API qui permettent de savoir quand une image est réellement affichée - et non plus seulement quand le navigateur l’a téléchargée.
Prenons aussi l’exemple du Speed Index : il faut choisir une taille d’écran de référence pour le mesurer alors qu’on sait que les tailles d’écrans varient d’un device à l’autre. Par ailleurs, quand on observe le Speed Index, on fait comme si l’internaute n'interagissait pas jusqu’au chargement complet de la page, alors qu’on sait pertinemment que tout le monde commence à scroller avant la fin du chargement total d’une page et souhaite voir ce qu’il y a après la ligne de flottaison. Cet indicateur a le mérite d’exister, mais il ne peut pas traduire exactement l’expérience vécue par l’internaute.
Cela étant, malgré ses limites, le Synthetic Monitoring présente l’avantage d’offrir une stabilité que les données organiques n’ont pas, donc on en aura toujours besoin. C’est un moyen très efficace de détecter des changements dans la performance qui viennent de nous et non pas de l’environnement. Ces métriques sont toujours utiles sur du très long terme.
Par exemple, chez Wikipedia, nous avons régulièrement des pics de trafics localisés liés à l’actualité. Si cette augmentation de trafic inhabituel provient d’une région du monde où internet est généralement lent, ça peut avoir un impact sur nos KPI webperf globaux, alors qu’en réalité ça n’indique pas de changement de notre performance dans l’absolu.
A l’inverse, lorsque de nouveaux modèles de téléphones plus puissants sont adoptés massivement, les métriques webperf s’améliorent, mais ça ne dit rien non plus de notre performance réelle. Ca pourrait même masquer une baisse de notre webperf ! Quand on regarde l’évolution de la performance sur du long terme, il faut donc faire un travail approfondi pour distinguer les évolutions qui sont dues à l'environnement et celles qui sont dûes à notre propre performance. C’est là que le synthetic monitoring reste très utile.
Globalement, la vitesse de chargement et les performances web s’améliorent. Mais ce que je cherche à observer dans le cadre de mes recherches, c’est aussi l’augmentation des performances dans l’absolu et par rapport aux attentes, en dehors d’un contexte de navigation avec des téléphones toujours plus rapides et des réseaux toujours plus fluides. Et pourquoi pas, créer de nouveaux standards !
Que souhaiteriez-vous mesurer dans ce cas ?
Je voudrais aller vers des outils qui reproduisent ce que perçoit l’humain, au-delà du déclaratif. Si je reprends le cas de Wikipedia, contrairement à un site marchand qui peut faire des tests A/B, c’est très difficile de mesurer ce qu’un.e lecteur.rice a compris ou retenu d’une page. Pour ce faire, on s’appuie aujourd’hui par exemple sur le temps de consultation qui est pourtant loin d’être un indicateur fiable. On pourrait finalement se dire que si l’information est mieux présentée, la personne qui la lit doit moins passer de temps à la consulter pour trouver ce qu’elle cherchait.
D’ailleurs, prenons l’exemple des aperçus dans les SERP Google : est-ce que l’internaute ne va pas sur la page parce que le contenu de l’aperçu a donné des informations suffisantes ? Est-ce au contraire parce que ce n’était pas pertinent ? Comment mesurer ce que l’internaute a appris ?
La notion de temps étant très subjective, comment pensez-vous l’évaluer ?
Il reste beaucoup de pistes à explorer pour faire évoluer les indicateurs dont nous disposons, quel que soit le domaine, webperf comprise. J’aimerais ainsi me rapprocher des capacités humaines dans la possibilité d’évaluer le temps de chargement d’une page. Et d’ailleurs, si c’est plus rapide, est-ce que c’est toujours mieux ?
Différentes études ont montré que dans certains cas comme des comparateurs de prix, une recherche qui dure plus longtemps donne l’impression d’être plus complète… En réalité beaucoup de sites dans ce domaine pourraient tout à fait afficher leurs résultats instantanément mais les ralentissent délibérément, car par des tests A/B ils ont pu constater qu’ils obtenaient un meilleur taux de conversion ainsi. Il y a donc des cas ou des temps de chargement “lents”, ou ralentis intentionnellement, peuvent être plus rassurants. Tout dépend du contexte.
Tout l’enjeu de nos travaux de recherches actuels est de trouver le moyen de retranscrire le plus fidèlement possible l’expérience de navigation d’un humain, espérons que nous y arriverons, ou que nous nous en rapprocherons le plus possible !
Vous souhaitez être au courant de l'actualité webperf ?
Abonnez-vous à notre newsletter mensuelle !
