Blogf

Ce blog est encore en construction

CR de la conférence The Web Performance Landscape

Quelques mots sur la conférence et le talk

performance.now() est une conférence se déroulant à Amsterdam chaque année depuis 5 ans et produisant une quinzaine de talks internationaux sur des sujets divers liés à (vous l’aurez deviné) la performance web. Les speakers et les sujets sont sélectionnés par les organisateurs (pas de CFP). Les videos sont toutes présentes sur Youtube.

Ce talk ouvre le bal du jour 1 en proposant un état des lieux du paysage de la performance web en 2024. Sa présentatrice, Tammy Everts est CEO (Chief Experience Officer) chez SpeedCurve (un outil de mesure automatisée de la performance), c’est à dire qu’elle explique à des entreprises comment leurs usagers utilisent leur site. Un sujet sur lequel elle travaille d’ailleurs depuis une vingtaine d’année. En parallèle de ça, elle est co-chair de la conference, et elle est à l’origine du site WPOStats qui recense un ensemble d’études de cas sur l’impact des performances de grands sites sur leur utilisation.

Les chiffres et métriques évoqués dans ce compte-rendu ne seront pas forcément toujours sourcés mais sont tous présents dans le support de la conf (disponible dans le lien “slides” dans l’encart en haut de cet article).

On ne connait pas ce qu’on ne connait pas

Tammy Everts commence par rappeler qu’il est facile de ne pas savoir ce qu’on ne sait pas et re-présente succintement l’effet Dunning-Kruger (ndlr: son article sur wikipedia). La performance web est un sujet complexe en constante évolution qui nécessite donc d’apprendre à accepter l’inconfort (to be comfortable with being uncomfortable) et accepter de poser les questions jusqu’à ce que cela devienne plus confortable. Cela passe aussi par l’exploration de ce qu’on ne connait pas.

En 2007 déjà, sortait un des ouvrages majeurs de la performance web, le livre High Performance Web Sites (cf. Quelques ressources en plus). Mais à l’époque l’étude de la performance était différente d’aujourd’hui:

18 ans plus tard, on a progressé sur beaucoup de ces points, mais nous n’en savons toujours pas assez sur nos utilisateurs, leur utilisation de nos applications, et plus largement sur l’efficacité de nos optimisations.

Connait-on nos utilisateurs

En parlant de nos utilisateurs, qui sont-ils ? On sait qu’il existe 5.52 milliards d’utilisateurs du web. Difficile de s’imaginer ce que cela représente en terme de diversité.

Quelques métriques en vrac :

Alors pourquoi est-ce que la plupart des développeurs développent avec une mentalité iPhone first ? La fracture que cela créé s’accentue chaque année car la différence de performance entre les appareils des utilisateurs riches et pauvres n’est pas compensée par les applications qui en demandent toujours plus.

Inequality is growing faster than the bottom-end can improve.

En français: l’inégalité progresse plus rapidement que ne peuvent s’améliorer les couches les plus pauvres.

Citation issue de la série d’articles (en) The Performance Inequality Gap par Axel Russel

D’ailleurs Tammy Everts montre ensuite une illustration sur l’évolution des LCP et INP (deux métriques des Core Web Vitals présentées un peu plus tard dans la présentation) dans le monde sur les smartphones Android. On voit très nettement des améliorations sur ces métriques à l’échelle globale mais la distinction entre les pays pauvres et les pays riches est toujours notables.

De la même manière, les vitesses de téléchargement moyennes sont toujours très disparates dans le monde. De nombreux pays (en Afrique, en Asie central, en Amérique Central) peinent à dépasser 50 Mbps tandis que d’autres en sont déjà à 200/250 Mbps.

Si vous réalisez un service pour un public mondial, c’est quelque chose qu’il faut absolument garder en tête.

Comprend-on nos métriques

Des métriques sur la performance web il en existe plein, et cela peut vite devenir écrasant lorsque l’on débute dans le sujet.

Les plus connues sont les Core Web Vitals introduites par Google: LCP(Largest Contentful Paint), CLS(Cumulative Layout Shift), et INP(Interaction to Next Paint). L’idée derrière ces métriques est de nous aider à comprendre la perception qu’ont nos utilisateurs de la performance (affichage du contenu, temps de réaction..) de l’application. Et ces métriques ont été un très bon moyen de sensibilisation.

Néanmoins, quelques petites mises en garde sur ces métriques. La première c’est qu’elles ne sont pas couvertes à 100% par tous les navigateurs (par exemple le CLS n’est supportée que par Chrome, et aucune ne l’est par Safari). De plus elles ne sont pas totalement supportées par les SPAs. Alors même que Chrome n’est utilisé “que” par 66% des utilisateurs et que 18% utilisent Safari. Cela peut sembler peu, mais souhaite-t-on n’avoir aucune visibilité sur la performance pour 1 de nos utilisateurs sur 5 ? La seconde est que la corrélation entre les seuils “Good”, “Needs improvement” et “Poor” n’est pas cohérente. De plus, elle n’est pas assez précise pour prendre en compte les contextes des sites.

En conclusion :

  1. Nous créons nos sites principalement pour des devices iOs
  2. Nous monitorons principalement pour Chrome
  3. Les métriques les plus populaires ne couvrent pas Safari
  4. Nos objectifs ne sont peut-être pas les bons

Nous sommes donc à la croisée des chemins.

L’autre point c’est que les pages web deviennent de plus en plus lourdes (2MB en 2022 vs 2,7MB en 2024). Un des facteurs-clé est l’intégration de medias videos, dont la taille globale a presque doublé sur cette période. De manière légèrement moins significative, la taille globale du Javascript a aussi significativement augmenté. La taille médiane des bundles Javascript est passée de 547KB à 800KB. Tammy Everts analyse fréquemment des sites internet et a même relevé un site comportant 320 requêtes à des tierces parties, pour un poids total de 2125KB de Javascript ! Un comportement qu’on retrouve souvent dans les sites de medias. On note aussi un large écart entre la médiane et le 90ème percentile, notamment concernant les medias images et videos, ainsi que les scripts Javascript.

Car en parallèle de nos efforts nous faisons toujours les mêmes erreurs :

Et cela concerne aussi l’accessibilité. En pratique, il devrait y avoir une corrélation entre l’accessibilité et les performances: nous devons accorder autant d’importance à l’un et à l’autre. Mais dans la pratique 96,7% des pages ont des erreurs sur les règles WCAG (Web Content Accessibility Guidelines)

Alors si la performance est devenu un sujet pour beaucoup d’entreprises, pourquoi tous ces échecs et toutes ces erreurs ? Tammy Everts explore quelques pistes de réponses :

Conclusion

Si la lecture de ce compte-rendu ou le visionnage de la conférence donne l’impression de ne plus ou de ne pas savoir quoi que ce soit sur les performances web, c’est plutôt bon signe. Cela veut dire qu’on est soit au début de son apprentissage, soit qu’on commence à prendre conscience qu’il nous reste pleins de choses à apprendre et expérimenter. C’est le bon moment de se renseigner (en regardant les autres videos de la conférence par exemple)

ABA: Always Be Asking

Et retenez ces quelques questions:

Quelques ressources en plus

Tammy Everts mentionne en début de conférence, le livre High performances Web sites (2007) de Steve Souders, chez O’Reilly. Ce livre est centrée autours de 14 bonnes pratiques pour accélerer ses pages web.