Il y a du mouvement dans le petit monde des webperf. Pas de changements majeurs, mais suffisamment pour que les SEO s’en soucient et y regardent de plus près. Lors du Chrome Dev Summit, nous avons eu l’occasion d’en apprendre plus sur les mises à jour à venir de Lighthouse et ses nouveaux indicateurs ainsi que sur la volonté toujours plus forte de Google de rendre le web plus rapide pour les utilisateurs.
"},{"id":"text-2","type":"text","heading":"","plain_text":"Envie de gagner du temps ?\n\t\t \n Faites résumer cet article par l’IA en quelques secondes.\n \n \n \n Résumer avec l’IA\n \n \n \n Des nouveaux messages sur la vitesse des sites\nCette nouveauté ne vient pas réellement du Chrome Dev Summit, mais son annonce s’est faite en parallèle. Sur le blog de Chromium Google insiste sur le fait qu’ils veulent aider les utilisateurs à mieux appréhender la vitesse d’un site, qu’il soit lent ou rapide. L’idée étant que l’utilisateur soit prévenu le plus tôt possible qu’il s’apprête à charger une page plutôt lente ou plutôt rapide.\nPour cela Google fera plusieurs tests pour savoir quel type d’alerte sera le plus efficace. Pour le moment, voici un exemple qui nous est donné pour mieux comprendre ce qu’ils ont en tête :","html":"Envie de gagner du temps ?\n\t\t \n Faites résumer cet article par l’IA en quelques secondes.\n \n \n \n Résumer avec l’IA\n \n \n \n Des nouveaux messages sur la vitesse des sites\nCette nouveauté ne vient pas réellement du Chrome Dev Summit, mais son annonce s’est faite en parallèle. Sur le blog de Chromium Google insiste sur le fait qu’ils veulent aider les utilisateurs à mieux appréhender la vitesse d’un site, qu’il soit lent ou rapide. L’idée étant que l’utilisateur soit prévenu le plus tôt possible qu’il s’apprête à charger une page plutôt lente ou plutôt rapide.\nPour cela Google fera plusieurs tests pour savoir quel type d’alerte sera le plus efficace. Pour le moment, voici un exemple qui nous est donné pour mieux comprendre ce qu’ils ont en tête :
"},{"id":"text-3","type":"text","heading":"","plain_text":"Google se servira des données historiques pour déterminer si un site est lent ou rapide. À terme, l’idée serait d’aller plus loin et de ne plus se fier uniquement aux données historiques (les mêmes que dans Google Page Speed Insights) mais d’adapter l’alerte en fonction de l’appareil et de la connexion de l’utilisateur.\nAucune communication pour le moment sur la date de lancement ni sur les performances minimales à respecter pour ne pas être considéré comme un site lent. Google nous dit néanmoins qu’ils estiment ne pas être trop sévères et ne rien demander d’insurmontable aux développeurs.\nIl va donc falloir travailler vos webperf et cela tombe bien puisqu’avec le Chrome Dev Summit, de nouveaux indicateurs très intéressants ont été dévoilés.\nLighthouse et indicateurs de performance\nAvant toute chose, l’équipe de Google nous rappelle un fondamental de la webperformance, à savoir la distinction entre deux types d’indicateurs : les indicateurs de champs et les indicateurs de laboratoire. Les premiers ont l’énorme avantage de refléter le plus possible la réalité de ce que vivent les internautes et le second permet de faire des tests poussés à un instant T et de découvrir d’éventuels problèmes.\nLes données de champs étant sans doute les plus importantes, Google tente de les améliorer constamment pour mieux comprendre comment sont perçus les sites web par leurs internautes. C’est donc ainsi qu’ils ont décidé de mettre en place 3 nouveaux indicateurs qui permettront de mieux mesurer lorsqu’une page est jugée utilisable : Largest Contentful Paint, Total Blocking Time et le Cumulative Layout Shift.\nAvant de rentrer dans le détail de chaque indicateur, il faut savoir que deux d’entre eux vont venir remplacer, en termes d’importance, le FMP (first meaningful Paint) et le FCI (first CPU idle) dans les calculs de score de la page.\nLargest Contentful Paint\nLe LCP mesure le temps que met à s’afficher l’élément le plus large de la page (plus précisément du viewport de l’utilisateur). Cela permet théoriquement de mieux mesurer le temps que va mettre l’utilisateur à voir l’élément le plus important de la page.\nPour le moment, ce calcul est limité à quelques éléments tels que :","html":"Google se servira des données historiques pour déterminer si un site est lent ou rapide. À terme, l’idée serait d’aller plus loin et de ne plus se fier uniquement aux données historiques (les mêmes que dans Google Page Speed Insights) mais d’adapter l’alerte en fonction de l’appareil et de la connexion de l’utilisateur.\nAucune communication pour le moment sur la date de lancement ni sur les performances minimales à respecter pour ne pas être considéré comme un site lent. Google nous dit néanmoins qu’ils estiment ne pas être trop sévères et ne rien demander d’insurmontable aux développeurs.\nIl va donc falloir travailler vos webperf et cela tombe bien puisqu’avec le Chrome Dev Summit, de nouveaux indicateurs très intéressants ont été dévoilés.\nLighthouse et indicateurs de performance\nAvant toute chose, l’équipe de Google nous rappelle un fondamental de la webperformance, à savoir la distinction entre deux types d’indicateurs : les indicateurs de champs et les indicateurs de laboratoire. Les premiers ont l’énorme avantage de refléter le plus possible la réalité de ce que vivent les internautes et le second permet de faire des tests poussés à un instant T et de découvrir d’éventuels problèmes.\nLes données de champs étant sans doute les plus importantes, Google tente de les améliorer constamment pour mieux comprendre comment sont perçus les sites web par leurs internautes. C’est donc ainsi qu’ils ont décidé de mettre en place 3 nouveaux indicateurs qui permettront de mieux mesurer lorsqu’une page est jugée utilisable : Largest Contentful Paint, Total Blocking Time et le Cumulative Layout Shift.\nAvant de rentrer dans le détail de chaque indicateur, il faut savoir que deux d’entre eux vont venir remplacer, en termes d’importance, le FMP (first meaningful Paint) et le FCI (first CPU idle) dans les calculs de score de la page.\nLargest Contentful Paint\nLe LCP mesure le temps que met à s’afficher l’élément le plus large de la page (plus précisément du viewport de l’utilisateur). Cela permet théoriquement de mieux mesurer le temps que va mettre l’utilisateur à voir l’élément le plus important de la page.\nPour le moment, ce calcul est limité à quelques éléments tels que :
"},{"id":"text-4","type":"text","heading":"","plain_text":"Les images.\nLes vidéos.\nUn background avec une image.\nDes blocs HTML comme des <p> ou des <article>, etc.","html":"Les images.\nLes vidéos.\nUn background avec une image.\nDes blocs HTML comme des <p> ou des <article>, etc.
"},{"id":"text-5","type":"text","heading":"","plain_text":"D’autres éléments seront sans doute ajoutés au fur et à mesure, mais pour le moment les équipes de Google souhaitent garder cette mesure la plus simple possible.\nNous ne rentrerons pas ici dans les considérations techniques sur comment définir l’élément le plus large d’une page ou encore à quel moment exactement est enregistré le chargement. Ce qu’il faut surtout retenir c’est que le calcul se fait lorsque l’élément le plus large est entièrement visible pour l’utilisateur.\nVoici quelques exemples donnés par Google pour mieux comprendre ce qu’est le LCP.\nSur le premier exemple, nous pouvons déjà nous poser la question de la pertinence de cet indicateur.\nEst-ce bien l’image l’élément le plus important de la page ou le titre avec le texte ? La question se pose et il faut vous la poser également en fonction de vos pages.\nPour un site e-commerce, sur une fiche produit, il y a en effet fort à parier que ce soit l’image l’élément le plus large et le plus important de la page, et dans ce cas en effet cela a du sens de se concentrer sur l’optimisation de son affichage. En revanche, sur d’autres types de pages, cet indicateur n’aura peut-être pas beaucoup de sens et il ne faudra pas lui apporter autant d’importance.\nCe sera donc à vous d’arbitrer sur sa pertinence et le besoin de l’optimiser.\nMais alors, pourquoi donner autant d’importance à un indicateur qui semble aussi arbitraire ? Le LCP vient « remplacer » un autre indicateur qui est le First Meaningful Paint qui avait trop de biais pour être fiable. Pour commencer, le FMP était trop dépendant du FCP (à savoir les premiers éléments qui s’affichent sur votre page) et le score descendait drastiquement si le FCP et le FMP étaient trop éloignés, ce qui n’avait pas toujours de sens. De plus cet indicateur était trop sensible aux moindres changements de chargement dans la page. Enfin, le plus gênant restait le manque d’information sur ce que signifiait vraiment le « premier contenu significatif de la page ».\nDonc même si le LCP a des défauts, et sera sans doute amélioré avec le temps, il a tout de même l’énorme avantage d’être clair et transparent pour les webmasters.\nSource : https://web.dev/lcp/\nCumulative Layout Shift\nVoici un indicateur fort intéressant d’un point de vue utilisateur. N’avez-vous jamais eu la mauvaise surprise de vouloir cliquer ou « taper » sur un élément d’une page et que, sans prévenir, cet élément bouge et que vous vous retrouviez à cliquer sur autre chose ?\nhttps://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.webm\nC’est précisément ce que mesure cet indicateur.\nCes changements sont souvent dus au chargement asynchrone de ressources ou à des fichiers qui mettent trop longtemps à charger leurs animations ce qui peut être pénible et frustrant pour l’internaute.\nLe CLS est calculé via l’API Layout Instability, dont le principe est relativement simple. Elle calcule les changements de place fonction de la position de l’élément lors du début du chargement de la page. Si un élément a une hauteur de X et un décalage à gauche de Y au début du chargement et se retrouve ensuite en hauteur W et en décalage gauche de Z alors il est considéré comme instable.\nComment c’est calculé ?\nLe CLS est calculé via 2 éléments :","html":"D’autres éléments seront sans doute ajoutés au fur et à mesure, mais pour le moment les équipes de Google souhaitent garder cette mesure la plus simple possible.\nNous ne rentrerons pas ici dans les considérations techniques sur comment définir l’élément le plus large d’une page ou encore à quel moment exactement est enregistré le chargement. Ce qu’il faut surtout retenir c’est que le calcul se fait lorsque l’élément le plus large est entièrement visible pour l’utilisateur.\nVoici quelques exemples donnés par Google pour mieux comprendre ce qu’est le LCP.\nSur le premier exemple, nous pouvons déjà nous poser la question de la pertinence de cet indicateur.\nEst-ce bien l’image l’élément le plus important de la page ou le titre avec le texte ? La question se pose et il faut vous la poser également en fonction de vos pages.\nPour un site e-commerce, sur une fiche produit, il y a en effet fort à parier que ce soit l’image l’élément le plus large et le plus important de la page, et dans ce cas en effet cela a du sens de se concentrer sur l’optimisation de son affichage. En revanche, sur d’autres types de pages, cet indicateur n’aura peut-être pas beaucoup de sens et il ne faudra pas lui apporter autant d’importance.\nCe sera donc à vous d’arbitrer sur sa pertinence et le besoin de l’optimiser.\nMais alors, pourquoi donner autant d’importance à un indicateur qui semble aussi arbitraire ? Le LCP vient « remplacer » un autre indicateur qui est le First Meaningful Paint qui avait trop de biais pour être fiable. Pour commencer, le FMP était trop dépendant du FCP (à savoir les premiers éléments qui s’affichent sur votre page) et le score descendait drastiquement si le FCP et le FMP étaient trop éloignés, ce qui n’avait pas toujours de sens. De plus cet indicateur était trop sensible aux moindres changements de chargement dans la page. Enfin, le plus gênant restait le manque d’information sur ce que signifiait vraiment le « premier contenu significatif de la page ».\nDonc même si le LCP a des défauts, et sera sans doute amélioré avec le temps, il a tout de même l’énorme avantage d’être clair et transparent pour les webmasters.\nSource : https://web.dev/lcp/\nCumulative Layout Shift\nVoici un indicateur fort intéressant d’un point de vue utilisateur. N’avez-vous jamais eu la mauvaise surprise de vouloir cliquer ou « taper » sur un élément d’une page et que, sans prévenir, cet élément bouge et que vous vous retrouviez à cliquer sur autre chose ?\nhttps://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.webm\nC’est précisément ce que mesure cet indicateur.\nCes changements sont souvent dus au chargement asynchrone de ressources ou à des fichiers qui mettent trop longtemps à charger leurs animations ce qui peut être pénible et frustrant pour l’internaute.\nLe CLS est calculé via l’API Layout Instability, dont le principe est relativement simple. Elle calcule les changements de place fonction de la position de l’élément lors du début du chargement de la page. Si un élément a une hauteur de X et un décalage à gauche de Y au début du chargement et se retrouve ensuite en hauteur W et en décalage gauche de Z alors il est considéré comme instable.\nComment c’est calculé ?\nLe CLS est calculé via 2 éléments :
"},{"id":"text-6","type":"text","heading":"","plain_text":"L’impact fraction. Cela calcule à quel point un élément est instable dans le viewport entre 2 frames (images). Entre 2 images, cela va prendre en compte l’impact de l’élément instable sur la totalité du viewport actuel.","html":"L’impact fraction. Cela calcule à quel point un élément est instable dans le viewport entre 2 frames (images). Entre 2 images, cela va prendre en compte l’impact de l’élément instable sur la totalité du viewport actuel.
"},{"id":"text-7","type":"text","heading":"","plain_text":"Utilisons l’exemple donné par Google pour simplifier les choses.\nSur la première image (gauche) le bloc prend 50% du viewport. Sur la frame suivante (l’image de droite) le bloc est descendu sur le viewport et si on additionne son ancienne position et la nouvelle, cela prend 75% du viewport. L’instabilité de ce bloc a donc impacté 75% de l’écran et son indice d’impact fraction sera alors de 0.75.","html":"Utilisons l’exemple donné par Google pour simplifier les choses.\nSur la première image (gauche) le bloc prend 50% du viewport. Sur la frame suivante (l’image de droite) le bloc est descendu sur le viewport et si on additionne son ancienne position et la nouvelle, cela prend 75% du viewport. L’instabilité de ce bloc a donc impacté 75% de l’écran et son indice d’impact fraction sera alors de 0.75.
"},{"id":"text-8","type":"text","heading":"","plain_text":"La distance fraction. Cet indice est plus simple à comprendre puisqu’il mesure la distance parcourue par le bloc instable dans le viewport. Dans l’exemple ci-dessus, le bloc a bougé de 25% verticalement. Son indice de distance fraction sera donc de 0.25.","html":"La distance fraction. Cet indice est plus simple à comprendre puisqu’il mesure la distance parcourue par le bloc instable dans le viewport. Dans l’exemple ci-dessus, le bloc a bougé de 25% verticalement. Son indice de distance fraction sera donc de 0.25.
"},{"id":"text-9","type":"text","heading":"","plain_text":"Ce nouvel indicateur n’est pas évident à appréhender, prenons donc un cas concret toujours donné par Google.\nIci le bloc gris ne sera pas considéré comme instable puisqu’il ne bouge pas et ne prend pas plus de place entre 2 frames. En revanche le bloc vert, lui, sera considéré comme instable puisqu’avec l’arrivée du CTA « Click Me ! » il se retrouve plus bas dans la page.\nSi vous avez bien suivi, l’impact fraction sera de 50% puisque l’élément instable ne prend pas plus de place que sur la première image. Nous avons donc un score de 0.5.\nEn revanche la distance fraction sera de 14% puisque le bloc vert à changé de hauteur entre les 2 images. Nous avons donc un score de 0.14.\nLa layout shift score sera donc de : 0.5 x 0.14 = 0.07.\nIdéalement il faudrait qu’une page est un CLS équivalent à 0 mais Google est bien conscient que ce n’est pas toujours possible. Un CLS sera donc considéré comme bon s’il ne dépasse pas les 5.\nTotal blocking Time\nLe TBT permet de calculer le temps entre le FCP et le TTI où le « thread » a été bloqué assez longtemps pour potentiellement empêcher toute interaction avec la page.\n« Bloqué » ici signifie que le thread ne peut pas interrompre la tâche qui est en cours et le « assez longtemps » signifie qu’il est ainsi pendant au moins 50ms.\nLe total blocking time est donc la somme de tous ces moments.\nPrenons un thread classique d’un navigateur qui charge une page.\nNous pouvons voir 5 tâches prenant chacune plusieurs millisecondes. 3 d’entres elles sont considérées comme de longues tâches puisqu’elles prennent plus de 50 millisecondes.\nLes éléments en rouge seront donc considérés comme du « temps en trop » et seront calculés dans le TBT. Ce qui fera que sur les 560ms au total, 345ms seront considérées comme du TBT.\nIl s’agit d’un bon indicateur en complément du TTI (time to interactive) qui aujourd’hui prend tout de même 33% de la note globale de lighthouse.\nCet indicateur permettra de mieux comprendre quel est le temps perdu et où il est perdu dans nos différentes tâches pour également mieux comprendre pourquoi notre TTI est mauvais. Pour rappel, le TTI est calculé à partir du moment où le thread principal est libre pendant au moins 5 secondes (et peut donc accepter les inputs utilisateurs).\nUn lighthouse plus complet en 2020\nPour terminer ce point sur la webperformance, Google nous donne 3 autres « nouveautés » sur lighthouse.\nLa première étant la mise à jour du calcul des scores dès Janvier 2020 avec l’arrivée des nouveaux indicateurs.\nLa seconde étant l’arrivée des stack packs et des plugins. Les stacks packs seront des nouveautés natives à Lighthouse qui permettront de détecter automatiquement sur quel CMS vous êtes et vous donneront des recommandations spécifiques à ce CMS. Pour le moment WordPress est déjà disponible et d’autres arrivent tels que React, Magento ou AMP.\nLes plugins quant à eux seront développés par la communauté. Leur utilisation est donc plus ou moins sans limite !\nEnfin la troisième et dernière nouveauté concerne l’utilisation de Lighthouse sur des environnements de préproduction ou de développement. Lighthouse CI\npermettra d’automatiser des tests sur n’importe quel environnement, de les enregistrer, les partager avec son équipe, etc. Très utile donc pour vérifier en amont et tout au long du projet que des efforts sont bien faits du côté des webperformances.\nPrécisons pour terminer que l’essentiel des éléments de cet article provient du site https://web.dev/ et que nous avons simplement choisi de les simplifier et de ne vous donner que l’essentiel. Libre à vous cependant d’aller explorer tout ceci, de faire vos propres tests et de mettre en place le tracking de ces indicateurs sur vos pages !","html":"Ce nouvel indicateur n’est pas évident à appréhender, prenons donc un cas concret toujours donné par Google.\nIci le bloc gris ne sera pas considéré comme instable puisqu’il ne bouge pas et ne prend pas plus de place entre 2 frames. En revanche le bloc vert, lui, sera considéré comme instable puisqu’avec l’arrivée du CTA « Click Me ! » il se retrouve plus bas dans la page.\nSi vous avez bien suivi, l’impact fraction sera de 50% puisque l’élément instable ne prend pas plus de place que sur la première image. Nous avons donc un score de 0.5.\nEn revanche la distance fraction sera de 14% puisque le bloc vert à changé de hauteur entre les 2 images. Nous avons donc un score de 0.14.\nLa layout shift score sera donc de : 0.5 x 0.14 = 0.07.\nIdéalement il faudrait qu’une page est un CLS équivalent à 0 mais Google est bien conscient que ce n’est pas toujours possible. Un CLS sera donc considéré comme bon s’il ne dépasse pas les 5.\nTotal blocking Time\nLe TBT permet de calculer le temps entre le FCP et le TTI où le « thread » a été bloqué assez longtemps pour potentiellement empêcher toute interaction avec la page.\n« Bloqué » ici signifie que le thread ne peut pas interrompre la tâche qui est en cours et le « assez longtemps » signifie qu’il est ainsi pendant au moins 50ms.\nLe total blocking time est donc la somme de tous ces moments.\nPrenons un thread classique d’un navigateur qui charge une page.\nNous pouvons voir 5 tâches prenant chacune plusieurs millisecondes. 3 d’entres elles sont considérées comme de longues tâches puisqu’elles prennent plus de 50 millisecondes.\nLes éléments en rouge seront donc considérés comme du « temps en trop » et seront calculés dans le TBT. Ce qui fera que sur les 560ms au total, 345ms seront considérées comme du TBT.\nIl s’agit d’un bon indicateur en complément du TTI (time to interactive) qui aujourd’hui prend tout de même 33% de la note globale de lighthouse.\nCet indicateur permettra de mieux comprendre quel est le temps perdu et où il est perdu dans nos différentes tâches pour également mieux comprendre pourquoi notre TTI est mauvais. Pour rappel, le TTI est calculé à partir du moment où le thread principal est libre pendant au moins 5 secondes (et peut donc accepter les inputs utilisateurs).\nUn lighthouse plus complet en 2020\nPour terminer ce point sur la webperformance, Google nous donne 3 autres « nouveautés » sur lighthouse.\nLa première étant la mise à jour du calcul des scores dès Janvier 2020 avec l’arrivée des nouveaux indicateurs.\nLa seconde étant l’arrivée des stack packs et des plugins. Les stacks packs seront des nouveautés natives à Lighthouse qui permettront de détecter automatiquement sur quel CMS vous êtes et vous donneront des recommandations spécifiques à ce CMS. Pour le moment WordPress est déjà disponible et d’autres arrivent tels que React, Magento ou AMP.\nLes plugins quant à eux seront développés par la communauté. Leur utilisation est donc plus ou moins sans limite !\nEnfin la troisième et dernière nouveauté concerne l’utilisation de Lighthouse sur des environnements de préproduction ou de développement. Lighthouse CI\npermettra d’automatiser des tests sur n’importe quel environnement, de les enregistrer, les partager avec son équipe, etc. Très utile donc pour vérifier en amont et tout au long du projet que des efforts sont bien faits du côté des webperformances.\nPrécisons pour terminer que l’essentiel des éléments de cet article provient du site https://web.dev/ et que nous avons simplement choisi de les simplifier et de ne vous donner que l’essentiel. Libre à vous cependant d’aller explorer tout ceci, de faire vos propres tests et de mettre en place le tracking de ces indicateurs sur vos pages !
"},{"id":"text-10","type":"text","heading":"","plain_text":"ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)","html":"ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)
"}],"sections":[{"id":"text-1","heading":"Text","content":"Il y a du mouvement dans le petit monde des webperf. Pas de changements majeurs, mais suffisamment pour que les SEO s’en soucient et y regardent de plus près. Lors du Chrome Dev Summit, nous avons eu l’occasion d’en apprendre plus sur les mises à jour à venir de Lighthouse et ses nouveaux indicateurs ainsi que sur la volonté toujours plus forte de Google de rendre le web plus rapide pour les utilisateurs."},{"id":"text-2","heading":"Text","content":"Envie de gagner du temps ?\n\t\t \n Faites résumer cet article par l’IA en quelques secondes.\n \n \n \n Résumer avec l’IA\n \n \n \n Des nouveaux messages sur la vitesse des sites\nCette nouveauté ne vient pas réellement du Chrome Dev Summit, mais son annonce s’est faite en parallèle. Sur le blog de Chromium Google insiste sur le fait qu’ils veulent aider les utilisateurs à mieux appréhender la vitesse d’un site, qu’il soit lent ou rapide. L’idée étant que l’utilisateur soit prévenu le plus tôt possible qu’il s’apprête à charger une page plutôt lente ou plutôt rapide.\nPour cela Google fera plusieurs tests pour savoir quel type d’alerte sera le plus efficace. Pour le moment, voici un exemple qui nous est donné pour mieux comprendre ce qu’ils ont en tête :"},{"id":"text-3","heading":"Text","content":"Google se servira des données historiques pour déterminer si un site est lent ou rapide. À terme, l’idée serait d’aller plus loin et de ne plus se fier uniquement aux données historiques (les mêmes que dans Google Page Speed Insights) mais d’adapter l’alerte en fonction de l’appareil et de la connexion de l’utilisateur.\nAucune communication pour le moment sur la date de lancement ni sur les performances minimales à respecter pour ne pas être considéré comme un site lent. Google nous dit néanmoins qu’ils estiment ne pas être trop sévères et ne rien demander d’insurmontable aux développeurs.\nIl va donc falloir travailler vos webperf et cela tombe bien puisqu’avec le Chrome Dev Summit, de nouveaux indicateurs très intéressants ont été dévoilés.\nLighthouse et indicateurs de performance\nAvant toute chose, l’équipe de Google nous rappelle un fondamental de la webperformance, à savoir la distinction entre deux types d’indicateurs : les indicateurs de champs et les indicateurs de laboratoire. Les premiers ont l’énorme avantage de refléter le plus possible la réalité de ce que vivent les internautes et le second permet de faire des tests poussés à un instant T et de découvrir d’éventuels problèmes.\nLes données de champs étant sans doute les plus importantes, Google tente de les améliorer constamment pour mieux comprendre comment sont perçus les sites web par leurs internautes. C’est donc ainsi qu’ils ont décidé de mettre en place 3 nouveaux indicateurs qui permettront de mieux mesurer lorsqu’une page est jugée utilisable : Largest Contentful Paint, Total Blocking Time et le Cumulative Layout Shift.\nAvant de rentrer dans le détail de chaque indicateur, il faut savoir que deux d’entre eux vont venir remplacer, en termes d’importance, le FMP (first meaningful Paint) et le FCI (first CPU idle) dans les calculs de score de la page.\nLargest Contentful Paint\nLe LCP mesure le temps que met à s’afficher l’élément le plus large de la page (plus précisément du viewport de l’utilisateur). Cela permet théoriquement de mieux mesurer le temps que va mettre l’utilisateur à voir l’élément le plus important de la page.\nPour le moment, ce calcul est limité à quelques éléments tels que :"},{"id":"text-4","heading":"Text","content":"Les images.\nLes vidéos.\nUn background avec une image.\nDes blocs HTML comme des <p> ou des <article>, etc."},{"id":"text-5","heading":"Text","content":"D’autres éléments seront sans doute ajoutés au fur et à mesure, mais pour le moment les équipes de Google souhaitent garder cette mesure la plus simple possible.\nNous ne rentrerons pas ici dans les considérations techniques sur comment définir l’élément le plus large d’une page ou encore à quel moment exactement est enregistré le chargement. Ce qu’il faut surtout retenir c’est que le calcul se fait lorsque l’élément le plus large est entièrement visible pour l’utilisateur.\nVoici quelques exemples donnés par Google pour mieux comprendre ce qu’est le LCP.\nSur le premier exemple, nous pouvons déjà nous poser la question de la pertinence de cet indicateur.\nEst-ce bien l’image l’élément le plus important de la page ou le titre avec le texte ? La question se pose et il faut vous la poser également en fonction de vos pages.\nPour un site e-commerce, sur une fiche produit, il y a en effet fort à parier que ce soit l’image l’élément le plus large et le plus important de la page, et dans ce cas en effet cela a du sens de se concentrer sur l’optimisation de son affichage. En revanche, sur d’autres types de pages, cet indicateur n’aura peut-être pas beaucoup de sens et il ne faudra pas lui apporter autant d’importance.\nCe sera donc à vous d’arbitrer sur sa pertinence et le besoin de l’optimiser.\nMais alors, pourquoi donner autant d’importance à un indicateur qui semble aussi arbitraire ? Le LCP vient « remplacer » un autre indicateur qui est le First Meaningful Paint qui avait trop de biais pour être fiable. Pour commencer, le FMP était trop dépendant du FCP (à savoir les premiers éléments qui s’affichent sur votre page) et le score descendait drastiquement si le FCP et le FMP étaient trop éloignés, ce qui n’avait pas toujours de sens. De plus cet indicateur était trop sensible aux moindres changements de chargement dans la page. Enfin, le plus gênant restait le manque d’information sur ce que signifiait vraiment le « premier contenu significatif de la page ».\nDonc même si le LCP a des défauts, et sera sans doute amélioré avec le temps, il a tout de même l’énorme avantage d’être clair et transparent pour les webmasters.\nSource : https://web.dev/lcp/\nCumulative Layout Shift\nVoici un indicateur fort intéressant d’un point de vue utilisateur. N’avez-vous jamais eu la mauvaise surprise de vouloir cliquer ou « taper » sur un élément d’une page et que, sans prévenir, cet élément bouge et que vous vous retrouviez à cliquer sur autre chose ?\nhttps://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.webm\nC’est précisément ce que mesure cet indicateur.\nCes changements sont souvent dus au chargement asynchrone de ressources ou à des fichiers qui mettent trop longtemps à charger leurs animations ce qui peut être pénible et frustrant pour l’internaute.\nLe CLS est calculé via l’API Layout Instability, dont le principe est relativement simple. Elle calcule les changements de place fonction de la position de l’élément lors du début du chargement de la page. Si un élément a une hauteur de X et un décalage à gauche de Y au début du chargement et se retrouve ensuite en hauteur W et en décalage gauche de Z alors il est considéré comme instable.\nComment c’est calculé ?\nLe CLS est calculé via 2 éléments :"},{"id":"text-6","heading":"Text","content":"L’impact fraction. Cela calcule à quel point un élément est instable dans le viewport entre 2 frames (images). Entre 2 images, cela va prendre en compte l’impact de l’élément instable sur la totalité du viewport actuel."},{"id":"text-7","heading":"Text","content":"Utilisons l’exemple donné par Google pour simplifier les choses.\nSur la première image (gauche) le bloc prend 50% du viewport. Sur la frame suivante (l’image de droite) le bloc est descendu sur le viewport et si on additionne son ancienne position et la nouvelle, cela prend 75% du viewport. L’instabilité de ce bloc a donc impacté 75% de l’écran et son indice d’impact fraction sera alors de 0.75."},{"id":"text-8","heading":"Text","content":"La distance fraction. Cet indice est plus simple à comprendre puisqu’il mesure la distance parcourue par le bloc instable dans le viewport. Dans l’exemple ci-dessus, le bloc a bougé de 25% verticalement. Son indice de distance fraction sera donc de 0.25."},{"id":"text-9","heading":"Text","content":"Ce nouvel indicateur n’est pas évident à appréhender, prenons donc un cas concret toujours donné par Google.\nIci le bloc gris ne sera pas considéré comme instable puisqu’il ne bouge pas et ne prend pas plus de place entre 2 frames. En revanche le bloc vert, lui, sera considéré comme instable puisqu’avec l’arrivée du CTA « Click Me ! » il se retrouve plus bas dans la page.\nSi vous avez bien suivi, l’impact fraction sera de 50% puisque l’élément instable ne prend pas plus de place que sur la première image. Nous avons donc un score de 0.5.\nEn revanche la distance fraction sera de 14% puisque le bloc vert à changé de hauteur entre les 2 images. Nous avons donc un score de 0.14.\nLa layout shift score sera donc de : 0.5 x 0.14 = 0.07.\nIdéalement il faudrait qu’une page est un CLS équivalent à 0 mais Google est bien conscient que ce n’est pas toujours possible. Un CLS sera donc considéré comme bon s’il ne dépasse pas les 5.\nTotal blocking Time\nLe TBT permet de calculer le temps entre le FCP et le TTI où le « thread » a été bloqué assez longtemps pour potentiellement empêcher toute interaction avec la page.\n« Bloqué » ici signifie que le thread ne peut pas interrompre la tâche qui est en cours et le « assez longtemps » signifie qu’il est ainsi pendant au moins 50ms.\nLe total blocking time est donc la somme de tous ces moments.\nPrenons un thread classique d’un navigateur qui charge une page.\nNous pouvons voir 5 tâches prenant chacune plusieurs millisecondes. 3 d’entres elles sont considérées comme de longues tâches puisqu’elles prennent plus de 50 millisecondes.\nLes éléments en rouge seront donc considérés comme du « temps en trop » et seront calculés dans le TBT. Ce qui fera que sur les 560ms au total, 345ms seront considérées comme du TBT.\nIl s’agit d’un bon indicateur en complément du TTI (time to interactive) qui aujourd’hui prend tout de même 33% de la note globale de lighthouse.\nCet indicateur permettra de mieux comprendre quel est le temps perdu et où il est perdu dans nos différentes tâches pour également mieux comprendre pourquoi notre TTI est mauvais. Pour rappel, le TTI est calculé à partir du moment où le thread principal est libre pendant au moins 5 secondes (et peut donc accepter les inputs utilisateurs).\nUn lighthouse plus complet en 2020\nPour terminer ce point sur la webperformance, Google nous donne 3 autres « nouveautés » sur lighthouse.\nLa première étant la mise à jour du calcul des scores dès Janvier 2020 avec l’arrivée des nouveaux indicateurs.\nLa seconde étant l’arrivée des stack packs et des plugins. Les stacks packs seront des nouveautés natives à Lighthouse qui permettront de détecter automatiquement sur quel CMS vous êtes et vous donneront des recommandations spécifiques à ce CMS. Pour le moment WordPress est déjà disponible et d’autres arrivent tels que React, Magento ou AMP.\nLes plugins quant à eux seront développés par la communauté. Leur utilisation est donc plus ou moins sans limite !\nEnfin la troisième et dernière nouveauté concerne l’utilisation de Lighthouse sur des environnements de préproduction ou de développement. Lighthouse CI\npermettra d’automatiser des tests sur n’importe quel environnement, de les enregistrer, les partager avec son équipe, etc. Très utile donc pour vérifier en amont et tout au long du projet que des efforts sont bien faits du côté des webperformances.\nPrécisons pour terminer que l’essentiel des éléments de cet article provient du site https://web.dev/ et que nous avons simplement choisi de les simplifier et de ne vous donner que l’essentiel. Libre à vous cependant d’aller explorer tout ceci, de faire vos propres tests et de mettre en place le tracking de ces indicateurs sur vos pages !"},{"id":"text-10","heading":"Text","content":"ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)"}],"media":{"primary_image":""},"relations":[{"rel":"canonical","href":"https://peakace.fr/blog/seo/google-vers-un-web-plus-rapide-nouveaux-indicateurs-de-performance-et-mise-a-jour-lighthouse/"},{"rel":"alternate","href":"https://peakace.fr/blog/seo/google-vers-un-web-plus-rapide-nouveaux-indicateurs-de-performance-et-mise-a-jour-lighthouse/llm","type":"text/html"},{"rel":"alternate","href":"https://peakace.fr/blog/seo/google-vers-un-web-plus-rapide-nouveaux-indicateurs-de-performance-et-mise-a-jour-lighthouse/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://peakace.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}