diff --git a/_data/authors.yml b/_data/authors.yml index 1a902466b..d6ca88ff4 100644 --- a/_data/authors.yml +++ b/_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 diff --git a/_posts/2024-10-29-we-love-speed-2024.md b/_posts/2024-10-29-we-love-speed-2024.md new file mode 100644 index 000000000..c4d637b33 --- /dev/null +++ b/_posts/2024-10-29-we-love-speed-2024.md @@ -0,0 +1,207 @@ +--- +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" +--- + +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 édition, 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’objectif de cette métrique est de refléter l’expérience utilisateur en mesurant la réactivité d’une application. +Elle observe le temps entre une action 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. Il s'agit de HTMX : une bibliothèque Javascript qui +permet d'ajouter des fonctionnalités de type SPA (Single Page Application) à une application web classique et de façon +non intrusive. Par exemple, on peut surcharger les liens `` pour qu’ils chargent une nouvelle page en AJAX grâce à un +attribut ajouté au HTML. Ce mode de fonctionnement est très intéressant, car il permet de garder une application web +classique avec tous ses comportements le temps que HTMX se charge. 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, 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ée le "DOM morphing". Grâce à ce processus le temps de chargement est réduit 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. + +>
+> Julie +> 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... +>
+ +>
+> ...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. +> Jules +>
+ +## 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 +rendu du navigateur. L’idée générale 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. Pour rappel, Crux est +une base de données qui contient des métriques de performance de sites web collectées par Google. +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. Le S8 est un appareil sur lequel on a +beaucoup de données et qui représente à l'heure actuelle une bonne représentation des capacités de l'utilisateur moyen. +L’INP est une métrique qui peut être influencée par des interactions qui ne sont pas prévues par les devs. Par exemple, +on a été étonnés de constater que lorsque les temps de chargement sont un poil trop longs à leur goût, les utilisateurs +se mettent à cliquer partout 🤷 C’est pourquoi il est important de se baser sur des données réelles. + +![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 +afin qu’elles correspondent aux navigateurs de nos utilisateurs, on évite des transformations inutiles qui +augmenteraient le poids de nos fichiers Javascript. + +Une nouvelle fonctionnalité de React appelée RSC (React Server Components) permet de 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 d’améliorer le temps d’interaction et +donc 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 `