feat(posts): We love speed 2024

_data/authors.yml

@@ -132,6 +132,7 @@ j_menan:
   url: https://twitter.com/julien_menan
 j_nginn:
   name: Julie Nginn
+  avatar: https://ca.slack-edge.com/T108ZKPMF-U01FQRQ8FT7-dfb12b21fb0d-192
 j_planckeel:
   name: Jérémy Planckeel
   url: https://github.com/jplanckeel

_posts/2024-10-29-we-love-speed-2024.md

@@ -0,0 +1,196 @@
+---
+layout: post
+title: We love speed 2024 ❤️
+description: Retour sur la conférence We love speed 2024 ❤️, une conférence annuelle axée sur la performance du web.
+author: [ j_nginn, j_poissonnet ]
+tags: [ performance, conference, webperf, javascript, react, web, frontend ]
+color: rgb(251,87,66)
+language: fr
+thumbnail: "images/posts/2024-10-29-we-love-speed-2024/welovespeed_2024-1709240237.jpg"
+---
+
+Cette année, nous avons eu la chance de participer à la conférence We love speed, une conférence annuelle axée sur la
+performance du web. C’est un domaine qui nous passionne et nous sommes très content d’avoir pu y assister.
+Le thème de cette année, c’est l’INP. En effet, cette métrique de performance a été ajoutée aux core web vitals par
+Google récemment https://developers.google.com/search/blog/2023/05/introducing-inp?hl=fr
+L’idée de cette métrique est de se rapprocher de l’expérience de l’utilisateur envers la réactivité d’une application
+web. Cette métrique observe le temps entre une interaction utilisateur et une réponse visuelle de notre interface.
+
+![L'équipe frontend à la we love speed](/images/posts/2024-10-29-we-love-speed-2024/team_picture.jpeg)
+
+## HTMX, le nouvel atout pour vos projets SSR - [Ewen Quimerc‘h](https://ewen.quimerch.com/)
+
+Lors de ce talk, nous avons découvert un outil très intéressant pour améliorer l’expérience utilisateur d’une
+Il s'agit de HTMX : une bibliothèque Javascript qui permet d’améliorer l’expérience utilisateur en ajoutant des
+fonctionnalités de type SPA (Single Page Application) à une application web classique et de façon non intrusive.
+Par exemple, on peut charger un CDN de manière asynchrone, ou encore charger des images en avance.
+C’est-a-dire que si HTMX venait à ne pas démarrer, votre application web se comporterait de la même manière, mais sans
+les améliorations de temps d’interaction.
+
+HTMX surcharge la manière dont vos liens et images vont être chargés par le navigateur.
+Ainsi, lors de la prochaine interaction avec le navigateur, ce dernier sera déjà prêt à servir les ressources.
+Le principe de HTMX consiste à ajouter des balises HTML spécifiques dans le DOM qu'il va lire et en déduire les
+comportements à son chargement.
+Cette manipulation est appelé le "DOM morphing". Grâce à ce processus le temps de chargement est réduite et on évite
+l'effet "blink" (page blanche lors du chargement de la page).
+Il est à noter que ces comportements ne sont qu’un embellissement proposé par HTMX, il est tout à fait possible
+d’ajouter par exemple l’attribut `preload` sur une balise `a` pour demander le chargement en avance du lien par le
+navigateur.
+
+> <div style="display: flex">
+> <img src="https://ca.slack-edge.com/T108ZKPMF-U01FQRQ8FT7-dfb12b21fb0d-192" alt="Julie" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> Comme nous utilisons React pour notre application, l'utilisation de HTMX n'est pas vraiment utile.
+> Il est déjà possible avec React de précharger les ressources en avance. Mais ça reste un outil intéressant...
+> </div>
+
+> <div style="display: flex">
+> ...effectivement, HTMX semble être intéressant, mais on se retrouve à ajouter
+> beaucoup d'attributs dans le HTML. Ça peut le rendre le markup moins lisible. Et en plus, ça donne l'impression de recoder les comportements du navigateur.
+> <img src="/images/avatar/j_poissonnet.jpg" alt="Jules" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> </div>
+
+## React / Next vs INP - [Jean-Pierre Vincent](https://www.linkedin.com/in/jeanpierrevincent/)
+
+Le deuxième talk a une place particulière dans notre cœur ❤️ puisqu’il a été donné par notre cher Jean-Pierre Vincent,
+qui a audité les performances du web de Bedrock, il y a deux ans.
+Lors de ce talk, Jean-Pierre nous a donné la feuille de route pour éviter au mieux la déferlante de Javascript que vos
+utilisateurs reçoivent au chargement de votre site.
+
+![JS Tsunami storming your users](/images/posts/2024-10-29-we-love-speed-2024/js_tsunami.jpeg)
+
+L'INP (Interaction to Next Paint) est une métrique qui mesure le temps entre une interaction utilisateur et le prochain.
+L’idée générale, c'est de pouvoir mesurer l’incapacité du navigateur à réagir. Après avoir récupéré des mesures, il est
+bon de
+se rappeler qu’il y a un biais de selection pour les données de Crux. En effet, il n’est calculé que sur les appareils
+Google (c’est le principe). Une fois qu’on a récolté des métriques de performance de nos utilisateurs, si on veut
+travailler sur notre site web et avoir une bonne idée du ressenti de nos utilisateurs, l’idéal est de tester avec un
+véritable Samsung S8 par exemple.
+L’INP est une métrique qui peut être influencée par des interactions qui ne sont pas prévues par les devs. C’est
+pourquoi il est important de se baser sur des données utilisateurs, car on est très souvent étonné de voir que quand les
+temps de chargement sont un poil trop long à leur goût, ils se mettent à cliquer partout 🤷
+
+![INP est bousculé par la charge de js!](/images/posts/2024-10-29-we-love-speed-2024/inp_charge.jpeg)
+
+Parmi les bonnes pratiques qu’on peut appliquer dès maintenant, et qui je dois le dire m’a paru un peu contre-intuitif :
+Faire passer Babel sur les node_modules.
+En fait, du point de vue d’un développeur, on peut se dire que cela va augmenter les temps de build drastiquement, et on
+aurait sûrement raison. Mais en fait, il faut voir le bénéfice qu’il y a derrière. Si on personnalise les règles Babel
+pour qu’elles correspondent aux navigateurs de nos utilisateurs, on s’évite des transformations inutiles qui
+augmenteraient le poids de nos fichiers Javascript.
+
+Une nouvelle fonctionnalité de React appelée RSC (React Server Components) permet combiner le rendu côté serveur avec
+l'interactivité côté client.
+Les RSC aident à réduire la taille du JavaScript dans le navigateur ce qui permet de réduire le temps d'interaction et
+de ce fait améliore grandement l'expérience utilisateur.
+Vous l’aurez compris, c’est l’ennemi n°1 de Jean-Pierre (et de vos navigateurs) !
+Le principe est de rendre les composants côté serveur et de faire en sorte que ces derniers ne rendent que du HTML, qui
+ne sera pas hydraté côté client.
+L’étape de réhydratation est une étape importante et trop souvent sous-estimée. Il s’agit d’une nouveauté de React qui
+est prometteuse et qui est déjà présente dans Next.js.
+
+Pour nous montrer un exemple concret d’abus de JavaScript : il a montré du code Bedrock 😅.
+Il s’agit d’un FlameGraph du rendu de notre `<Footer />` côté app web. Il y a une quantité conséquente de JS car nous
+faisions ce qu’on appelle du CSS-in-JS.
+Vous l’avez deviné, c’est la partie "in-JS" qui pose un problème. Cela signifie que pour appliquer du style sur notre
+site, c’est le Javascript qui s’en charge. Or dans un composant, comme le `<Footer />`, il y a beaucoup d’éléments et chacun va
+avoir besoin son propre style. Si l’idée de colocaliser le CSS dans le JS n’est pas nocive en soi, le plus gros problème
+était l'utilisation de [Styled-Components](https://styled-components.com/) qui calcule le style au moment du rendu, le rendant donc plus long.
+FYI: Entre temps, nous avons chez Bedrock entamé une migration pour quitter Styled-Components au profit de [Linaria](https://linaria.dev/) pour le projet web et [Vanilla Extract](https://vanilla-extract.style/) pour le projet smart TV.
+
+![Flamegraph du Footer de Bedrock](/images/posts/2024-10-29-we-love-speed-2024/flamgraph.jpeg)
+
+Autre information qui nous concerne chez Bedrock, au moment d’écrire ces lignes, nous sommes en train de mettre en
+production la migration de React 17 vers React 18 sur le projet web.
+D’après les retours d’expérience de Jean-Pierre, cette version de React aura un impact positif sur l’INP car il permet de faire moins de `render`.
+
+Enfin, Jean-Pierre nous laisse avec un ultime conseil pour que nos applications web soient pérennes : “Monitores (au
+moins une fois dans ta vie) l’origine des INP avec un vrai utilisateur.”
+
+> <div style="display: flex">
+> <img src="https://ca.slack-edge.com/T108ZKPMF-U01FQRQ8FT7-dfb12b21fb0d-192" alt="Julie" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> J'ai bien aimé ce talk ! J'ai trouvé que sa présentation était très accessible, il a su vulgariser des concepts et rendre un sujet chiant (la performance) intéressant 👏
+> </div>
+
+## Débogage des performances à l’aide des DevTools : Mise en pratique approfondie - [Umar Hansa](https://umaar.com/)
+
+Avoir un œil sur ses performances, c’est essentiel pour pouvoir avancer dans la bonne direction et s’assurer qu’on
+fournit à nos utilisateurs une expérience optimale. Fort heureusement pour nous les devs, on est bien lotis avec de très
+bons outils. Il suffit d’ouvrir les Chrome DevTools pour s’en rendre compte. Il nous a été présenté lors de ce talk
+comment bien utiliser les DevTools pour mesurer les performances de nos applications web et se mettre à la place de
+nos utilisateurs. Par exemple, on peut brider son réseau et son CPU pour simuler une connexion 3G et un CPU lent. Dans
+cette présentation, on nous a quand même rappelé que les DevTools ne sont pas une solution miracle, il est important de
+tester sur de vrais devices pour le ressenti.
+
+Pour ce qui est de l'interprétation des données, une myriade d'outils sont à notre disposition pour nous aider à
+comprendre ce que nous voyons. Par exemple, on peut ajouter des annotations dans le flamegraph comme des labels, des
+diagrammes ou encore des plages de temps. On peut aussi utiliser des custom tracks pour suivre des événements
+spécifiques. Au sein de notre application, on peut utiliser l’API User Timing pour ajouter des points de repère dans
+notre code et ainsi mieux comprendre ce qui se passe au déclenchement d'événements spécifiques.
+
+## Web Performance Testing - [Estela Franco](https://x.com/guaca)
+
+On a aussi eu un talk sur l'intégration de Lighthouse, un outil de Google pour mesurer la performance de nos
+applications web, dans une CI. Cela permet de détecter les problèmes de performance avant qu'ils ne soient déployés en
+production. Il est possible de mettre des warnings, voire des erreurs empêchant de merger, si la performance de notre
+application web ne respecte pas les standards que nous nous sommes fixés. L'idée est de s'assurer que la performance de
+notre application web est toujours au top et ne se dégrade pas dans le temps.
+![Key takeaways from the talk](/images/posts/2024-10-29-we-love-speed-2024/Key%20Takeaways.jpeg)
+
+> <div style="display: flex">
+> <img src="https://ca.slack-edge.com/T108ZKPMF-U01FQRQ8FT7-dfb12b21fb0d-192" alt="Julie" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> Y'a moyen qu'on l'ajoute au projet smart TV, mais plus pour générer un rapport de performance quotidien plutôt que de le faire pour chaque push ou merge. 
+> </div>
+
+## Comment les navigateurs chargent VRAIMENT les pages web - [Robin Marx](https://x.com/programmingart)
+
+Dans ce qui est probablement le talk le plus technique de la journée, on nous a expliqué comment les navigateurs
+chargent les différentes ressources nécessaires à l'affichage d'une page web. Plus spécifiquement, on nous a expliqué
+comment les navigateurs interprètent le HTML pour déterminer quelles ressources charger en priorité.
+
+Le talk était très intéressant, mais la conclusion est un peu frustrante : il est pour le moment impossible de prévoir
+l'ordre de chargement des ressources par le navigateur à partir du même HTML. En effet, les navigateurs ont des
+comportements différents entre eux et même par version 🤯. Chrome a, par exemple, un comportement très différent cette
+année
+par rapport à deux ans en arrière.
+
+Même si on est tenté de vouloir contrôler le chargement des ressources, il est important de se rappeler que le
+navigateur
+est très bien optimisé pour charger les ressources de manière efficace. Il est donc préférable de laisser le navigateur
+faire son travail plutôt que de vouloir le contrôler. L'attribut `preload` est un bon exemple de ce que l'on peut faire
+pour aider le navigateur à charger les ressources de manière plus efficace. Il faut cependant l'utiliser avec parcimonie
+et de manière chirurgicale pour ne pas interférer avec le travail du navigateur.
+
+![Preload with surgical precision](/images/posts/2024-10-29-we-love-speed-2024/preload_surgical.jpeg)
+
+
+## Mais que fait la police ? - [Eroan Boyer](https://x.com/eroan)
+
+Pour finir, on a eu un talk sur les polices de caractères. Elles sont essentielles pour l'identité visuelle de nos
+applications web, mais elles peuvent aussi être une source de problèmes de performance. En effet, les polices de
+caractères peuvent être très lourdes et ralentir le chargement de nos pages. Il est donc important de bien les choisir
+et de les optimiser pour garantir une bonne performance. Il existe plusieurs techniques pour optimiser les polices,
+notamment en réalisant un subset de la police pour ne télécharger que les glyphes dont on a besoin. (En français, on a
+besoin que de 165 glyphes comparé à 528 pour le latin).
+Il existe des outils pour nous aider à réaliser ces subsets comme: [Font Subsetter](https://everythingfonts.com/subsetter), [fontTools](https://fonttools.readthedocs.io/) ou
+[Glyphanger](https://www.zachleat.com/web/glyphhanger/) .
+> <div style="display: flex">
+> Attention à ne pas abuser des subsets, car cela peut entraîner des problèmes de lisibilité du texte. Le fameux t🠉fu .
+> <img src="/images/avatar/j_poissonnet.jpg" alt="Jules" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> </div>
+
+![Say no to tofu](/images/posts/2024-10-29-we-love-speed-2024/tofu.jpeg)
+
+Il est aussi possible de minimiser le nombre de fichiers en utilisant des polices variables. Un bon exemple, c'est la police
+ Roboto Flex, qui est customisable et permet ainsi de pouvoir réduire le nombre de fichiers nécessaires à charger. Il est là aussi,
+possible de sélectionner les variations que l'on souhaite pour réduire encore plus le poids de la police.
+
+# Conclusion
+
+Cette année, l'accent a été mis sur l'INP et la manière de l'améliorer. Il est important de garder en tête que l'INP est
+une métrique qui mesure l'expérience utilisateur,il est donc essentiel de la garder à l'œil. Il est bon de
+rappeler
+que la performance est plus une habitude à prendre qu'un constat à réaliser. Une application performante c'est une expérience utilisateur améliorée et des utilisateurs satisfaits !
+
+Notre équipe est ressortie de cette conférence ravie et avec de nouvelles idées à mettre en place pour notre plateforme.
+La We love speed ❤️ est une conférence à ne pas manquer pour tous les passionnés de performance web, on vous recommande
+chaudement d'y assister si vous en avez l'occasion !