We ❤️ Speed organisait son 4e événement en cette fin d’année 2021, dans une nouvelle ville selon la tradition, après les éditions de Bordeaux, Lille et Lazy Loaded. Vous pouvez déjà retrouver l’intégralité des vidéos des conférences sur Youtube, ainsi qu’au sein du programme où sont aussi diffusés certains supports.
Cette édition avait donc lieu à Lyon, au sein du très beau Palais de la Bourse.
Voici ce que nous avons retenu des quelques conférences auxquelles nous avons pu assister :
Jérémy Wyler de Solocal et Amir Glatt de Duda : « Comment améliorer la web performance d’un parc de plus de 40 000 sites ? »
Jérémy Wyler, responsable SEO de Solocal, était sur place. Amir Glatt de Duda était malheureusement à distance.
Jérémy a commencé par nous présenter le contexte particulier des très nombreux sites gérés par Solocal pour ses clients, soit 40 000 sites de PME d’une dizaine de salariés. Là où le SEO classique s’appuie beaucoup sur le maillage de liens entre sites depuis l’arrivée de Google, ce n’est pas une caractéristique de la plupart de ces sites.
Les autres critères tels que la qualité/pertinence du contenu, et maintenant la performance, deviennent du coup plus importants. Solocal aide ses clients sur le premier sujet, mais a choisi de confier progressivement, depuis 2018, la gestion technique des sites à un tiers, le CMS en SaaS Duda.
Amir a ensuite présenté comment sa plateforme Duda prend en compte les Core Web Vitals de Google pour progressivement améliorer la plateforme et en faire bénéficier le million de sites hébergés, au delà des 40 000 de Solocal. Les optimisations présentées sont classiques, mais leur application à cette échelle a forcément un impact démultiplié qui fait du bien au Web (comme on peut le voir avec les gros efforts en cours ou prévus chez Wix et WordPress).
On peut noter l’usage de la bibliothèque JavaScript open source web-vitals.js de Google pour le RUM, une bibliothèque citée plusieurs fois au cours de la journée.
Le retour d’expérience de Solocal sur l’utilisation de Duda montre de bons scores de LCP et FID, mais beaucoup de sites gardent de mauvais scores à cause de widgets spécifiques migrés depuis l’ancienne plateforme Solocal. Une belle piste d’amélioration pour le futur.
Yoav Weiss : « LCP, ce que vous ne savez (peut-être) pas »
Yoav Weiss a malheureusement dû pré-enregistrer sa conférence en vidéo à cause du COVID, à défaut de venir sur place comme prévu. Il a heureusement pu être disponible en live pour répondre ensuite à quelques questions.
Yoav a bien rappelé ce qui existait avant la création par Google de l’indicateur Largest Contentful Paint des Core Web Vitals. Notamment, le fait que le Speed Index est un indicateur bien corrélé avec l’expérience utilisateur, mais qu’il est trop coûteux (analysant une séquence de screenshots de rendu) pour être applicable en Real User Monitoring (RUM). Avant la création de LCP, Google avait tenté First Contenful Paint (FCP) et First Meaningful Paint (FMP), mais l’algorithme de ce dernier n’était pas suffisamment satisfaisant.
Les retours d’expérience avec LCP montrent de fortes corrélations avec Speed Index et avec les métriques business, ce qui en valide la pertinence globale. Il reste cependant quelques limites dans la version actuelle, donc des évolutions sont encore à prévoir, notamment pour la prise en compte des médias à chargement/affichage progressif, comme les images et vidéos.
Yoav a ensuite présenté un certain nombre d’améliorations de performance qui impactent directement le LCP, de quoi expérimenter sur vos sites.
Si vous constatez des mesures de LCP qui ne vous semblent pas pertinentes ou si vous avez des suggestions d’amélioration, n’hésitez pas à les signaler au Web Performance Working Group, ou directement à Yoav sur Twitter.
Une question intéressante en fin de session, posée par Florent Bourgeois de TwicPics, concernait l’impact des Low Quality Image Placeholders (LQIP) sur LCP. Il est aujourd’hui négatif puisque les LQIP ne sont pas représentatives du rendu final. Le groupe de travail n’a pas encore d’avis définitif sur le sujet, ni de conviction sur la pertinence UX de cette technique.
Une autre question très pertinente concernait les bannières ou overlays utilisés pour le consentement à l’usage de cookies, qui arrivent généralement en fin d’affichage des pages, et sont généralement très imposants, donc deviennent le LCP. Yoav a répondu spontanément que cet élément pourrait être moins proéminent dans l’interface, mais nous savons que ce n’est pas toujours souhaité par les équipes qui veulent absolument recueillir ce consentement. Yoav a relayé la question sur Twitter, si vous voulez voir certains avis complémentaires.
Ludovic Lagatie et Bertrand Laot de Leroy Merlin : « L’architecture Micro-Front, un levier pour la webperf ? »
Ludovic et Bertrand nous ont présenté les enjeux pour Leroy Merlin – 5e site e-commerce en France en termes de trafic -, notamment le time to market qui posait problème avec le monolithe de l’ancienne architecture, et comment la nouvelle architecture micro-front y a répondu.
Afin d’éviter les lenteurs d’une architecture avec des pages complètement assemblées en front, sachant qu’il peut y avoir jusqu’à 30 composants différents dans une page, il a été décidé de faire de la génération côté serveur (Server Side Rendering).
Cela a cependant posé le problème des temps de réponse des différents services sollicités, et Leroy Merlin a astucieusement répartit ceux-ci entre primaires (critiques) et secondaires. Les primaires sont intégrés côté serveur pour servir une page utile le plus rapidement possible, et les secondaires sont lazy loadés par le front.
Pour compléter cette architecture et assurer une mise à jour optimale des ressources partagées, un système de bus événementiel a été mis en place pour pousser les mises à jour de cache sur les différents « étages ». Cela permet d’assurer la meilleure fraîcheur possible en limitant les sollicitations des services concernés.
Des informations intéressantes ont également été partagées sur la gestion des ressources front (CSS, JavaScript), ainsi que la gestion complexe des nombreuses et lourdes ressources de services tiers.
Au final, c’est l’une des meilleures conférences auxquelles nous avons pu assister lors de cette édition, avec des solutions concrètes et très bien présentées.
Josselin Buils de Manomano : « SPArtacUX, le projet qui a ramené la performance web au coeur de l’UX ManoMano »
Josselin Buils nous a montré dans cette conférence que l’évolution du site Manomano d’une architecture traditionnelle en Symfony et JavaScript vanilla en Single Page Application (SPA) React, puis en micro frontends, a fait chuter la performance et pénalisé le SEO.
Ce constat a conduit à une refonte complète, nommée SPArtacUX, toujours pour une SPA, mais avec un focus sur l’expérience utilisateur (UX), dont fait partie la performance.
Les optimisations faites sur cette SPA sont de multiples natures, avec un élément clef récurrent sur la génération tant que possible côté serveur, et le chargement en front d’éléments complémentaires uniquement quand ils deviennent utiles : SSR avec optimisation de l’utilisation du CDN, lazy loading de composants et d’images, réduction de la taille du DOM, etc.
Sans être allé dans la technique comme dans la conférence de Leroy Merlin, cela aura sans doute permis à certains de voir (et comprendre on l’espère) qu’une approche SPA nécessite beaucoup de réflexions au-delà du choix du framework de développement (ici React et Next.js) afin d’obtenir de bonnes performances.
Réussir un tel projet a nécessité une équipe d’une centaines de développeurs front end, ce qui montre la complexité.
Anthony Ricaud : « Encore plus rapide que les SPA ? »
L’objectif d’Anthony avec cette conférence était, justement par rapport à celle de Manomano, de montrer que la voie SPA n’est pas la seule exploitable quand on souhaite construire des interfaces riches en interactions.
Une base HTML standard fournit d’emblée de très bonnes performances, et des bibliothèques JavaScript telles que Hotwire Turbo et Stimulus permettent d’enrichir facilement les comportements dynamiques, sans pénaliser autant la performance que dans le cas de SPA traditionnelles.
À la différence des frameworks SPA qui s’enrichissent petit à petit de Server Side Rendering (SSR) et d’hydratation progressive pour pallier leurs soucis de performance, il est question ici d’enrichir fonctionnellement en respectant une base déjà performante.
Le sujet n’est pas de dire que les SPA ne devraient pas exister, plutôt qu’il y a de nombreux projets développés de nos jours où ce n’est certainement pas la solution la plus optimale pour la performance.
Tim Vereecke : « Responsive RUM »
Tim Vereecke n’a malheureusement pas pu faire sa conférence en présence non plus, il a néanmoins été disponible pour une séance de questions/réponses.
Tim travaille chez Akamai, qui dispose d’une solution de Real User Monitoring nommée mPulse, issue du rachat en 2017 de Soasta, un pure player de la supervision de performance. Tim développe également un site international destiné aux passionnés de modélisme, où il peut expérimenter beaucoup de choses concernant la performance, avec mPulse pour voir les conséquences.
Un constat fait par Tim est que la plupart des analyses de données RUM se limitent encore à des segmentations arbitraires entre mobiles, tablettes et ordinateurs. Il existe pourtant aujourd’hui une multitude d’autres axes différenciant notablement les visiteurs et leurs outils de navigation, avec des impacts notables sur la performance.
Parmis ceux-ci, on peut citer :
- La densité d’écran, qui varie de 1 sur la plupart des ordinateurs à 4 sur les smartphones haut de gamme, sachant que la densité 1 n’existe plus sur les smartphones en circulation. Un souci particulier pour l’analyse des densités d’écrans des utilisateurs est qu’il n’y a pas que quelques valeurs entières, mais une multitude de valeurs décimales intermédiaires. Cela a conduit Tim à consolider les valeurs dans seulement 3 groupes : 1x, 1.5x et 2x.
- Les largeurs de viewports (plutôt que d’écrans) sont aussi réparties sur de très nombreuses valeurs, ce qui conduit Tim à plutôt classer les visites selon la version responsive qu’elles « voient », selon les breakpoints majeurs qui s’appliquent.
- Le souhait de l’utilisateur avec le paramètre data-saver (ou potentiellement la décision du navigateur) de réduire le volume de données transférées, pour améliorer la performance ou consommer moins son forfait de données. Cela peut conduire le site à compresser plus les images ou ne pas fournir certaines fonctionnalités volumineuses, donc il est important de pouvoir les isoler dans les analyses de performance.
- La présence de bloqueurs de publicités et de trackers, de plus en plus courante, a aussi un impact sur la performance, donc de même il est important de pouvoir faire cette segmentation.
- La langue de la page consultée est également un axe d’analyse important, les longueurs de textes pouvant varier et impacter notamment le Largest Contentful Paint. La présence de langues Right To Left (RTL) pourrait aussi avoir un impact.
Cette conférence aura bien montré la difficulté d’analyse qu’induit une supervision de performance en RUM, par rapport à une surveillance en mode synthétique avec des paramètres bien moins nombreux et plus stables.
La puissance du RUM est indéniable pour avoir des informations concrètes sur l’expérience des visiteurs, mais une bonne exploitation nécessite beaucoup plus d’attention.
Cet article vous a intéressé et vous souhaitez en savoir plus ?