Update conclusion + lightouse CI

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

@@ -41,15 +41,15 @@ d’ajouter par exemple l’attribut `preload` sur une balise `a` pour demander
 navigateur.
 
 > <div style="display: flex">
-> <img src="https://ca.slack-edge.com/T108ZKPMF-U01FQRQ8FT7-dfb12b21fb0d-192" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> <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" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> <img src="/images/avatar/j_poissonnet.jpg" alt="Jules" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
 > </div>
 
 ## INP vs JS
@@ -79,8 +79,7 @@ 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.
+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.
@@ -96,27 +95,26 @@ Pour nous montrer un exemple concret d’abus de JavaScript : il a montré du co
 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
+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` 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`.
+é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 à Bedrock, nous sommes au moment d’écrire ces lignes en train de mettre en
-production la migration de React 17 vers React 18 du côté app web.
-D’après les retours d’expérience de Jean-Pierre, React 18 est bon pour l’INP car il permet de faire moins de `render`.
+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" style="padding: 0;border-radius: 50%; height: 70px; margin: 10px">
+> <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>
 
-## Performance with Chrome DevTools
+## Performance avec Chrome DevTools
 
 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
@@ -132,16 +130,14 @@ diagrammes ou encore des plages de temps. On peut aussi utiliser des custom trac
 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 Perf Testing
+## Tester la performance avec Lighthouse CI
 
-On a aussi eu un talk sur la mise en place de lighthouse, qui est un outil de Google pour mesurer la performance de nos
-applications web, dans une CI. L'outil en local est très bien, mais il est encore mieux de l'intégrer dans une CI pour
-pouvoir tester la performance de notre application web à chaque push. 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,
-si la performance de notre application web ne respecte pas les standards que nous nous sommes fixés. L'idée derrière la
-mise en place de Lighthouse dans une CI est de s'assurer que la performance de notre application web est toujours au
-top et ne se dégrade pas dans le temps. Il est en effet plus facile de corriger un problème de performance lorsqu'il
-minimal plutôt que lorsqu'il est déjà bien installé.
+On a aussi eu un talk sur la mise en place de [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci). Avec cet outil de Google, nous pouvons désormais mesurer la performance de notre application directement dans notre CI, ce qui peut être pratique pour garder un oeil sur les éventuelles régressions.
+L'outil en local est très bien, mais il est encore mieux de l'intégrer dans une CI pour automatiser le processus. Cela permet de détecter les problèmes de
+performance avant qu'ils ne soient déployés en production. Il est possible de générer des warnings, voire des erreurs,
+en cas de non-respect des standards de performance que nous avons définis. L'idée derrière la
+mise en place de Lighthouse CI est de s'assurer que la performance de notre application web est toujours au
+top et ne se dégrade pas dans le temps. Il est en effet plus facile de corriger une régression lorsqu'on peut savoir exactement quelle Pull Request ou commit l'a introduite.
 ![Key takeaways from the talk](/images/posts/2024-10-29-we-love-speed-2024/Key%20Takeaways.jpeg)
 
 ## How browsers really load pages
@@ -184,10 +180,9 @@ possible de sélectionner les variations que l'on souhaite pour réduire encore
 # 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 et qu'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. Gardons en tête que la performance est un 
-moyen d'offrir une meilleure expérience utilisateur. 
+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, avec de nouvelles idées à mettre en place pour notre plateforme. 
+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 !