L’enjeu est de taille. Qui n’a jamais fait une recherche Google en décrivant ses symptômes, pour avoir une liste de potentielles pathologies ? C’est devenu presque instinctif. C’est pourquoi l’éducation et l’information médicale sont des enjeux cruciaux pour les acteurs de la santé : un patient bien informé sur un traitement est un patient qui en parlera à son médecin. Générer du trafic organique de qualité devient donc une préoccupation majeure.
Comment améliorer le trafic organique d’un site web ?
Sur le papier, c’est simple : obtenir un meilleur classement dans les recherches Google grâce au SEO (Search Engine Optimization) sémantique, c’est-à-dire un contenu pertinent et des backlinks. En réalité, les moteurs de recherche ont bien évolué ces dernières années. Un site qui remonte haut dans les recherches, ce n’est plus uniquement un site avec des mots-clés performants.
L’expérience utilisateur, ou UX, est le nouveau critère phare des moteurs de recherche. Un site fiable et de qualité aura plus de chance de trouver sa place dans le haut du classement.
“Les principaux systèmes de classement de Google visent à récompenser les contenus qui offrent une bonne expérience sur la page.” - Google
Sur quels critères est évaluée l’expérience utilisateur de mon site web ?
La liste est longue, retenons cinq points essentiels :
- La qualité de la navigation : le contenu principal des pages est simple à localiser, et facile d’accès ;
- La protection des données : les pages sont diffusées de manière sécurisées ;
- L’accessibilité : le site est utilisable par le plus grand nombre de personnes, intelligible pour les lecteurs d’écran ;
- L’affichage mobile : le site est adapté aux petits écrans ;
- La vitesse : l’expérience utilisateur n’est pas affectée par des temps de chargement longs.
Nous allons voir dans cet article comment, en monitorant simplement la performance, nous avons réussi à améliorer les temps de chargement de nos pages de 1 à 4 secs !
Comment optimiser la vitesse de mon site web ?
La vitesse de chargement est un pilier essentiel pour une bonne expérience utilisateur, et c’est notamment un indicateur fortement valorisé par les moteurs de recherche pour le ranking. À titre d’exemple, “plus de la moitié des visites sont abandonnées si une page mobile met plus de trois secondes à se charger.”
Pour améliorer ce temps de chargement, il y a plusieurs axes possibles à considérer d’un point de vue technique. Il faut avant tout maîtriser les technologies de son site web (que ce soit du code ou du no-code). Il est important de connaitre les points forts et inconvénients de la stack technique avant de chercher à optimiser les performances. Si un choix s’offre à vous, privilégiez les technologies modernes optimisées pour le SEO comme le framework React NextJS, qui permet de rendre le contenu des pages accessible statiquement par les crawlers.
Mais ce qui est vraiment important pour améliorer continuellement son site, c’est de suivre des indicateurs de performance pour aider au développement et maintenir un bon score de SEO technique.
Les signaux web essentiels (Core Web Vitals)
Les signaux web essentiels sont un groupe de métriques utilisées par Google pour estimer l’état de santé de l’expérience utilisateur d’un site web donné.
Trois métriques se démarquent :
- le Largest Contentful Paint (LCP) pour le temps de chargement
- le First Input Delay (FID) pour la réactivité
- le Cumulative Layout Shift (CLS) pour la stabilité visuelle à l’écran.
Schéma montrant les Core Web Vitals faisant partie des principaux indicateurs utilisés par Google pour évaluer l’expérience utilisateur d’un site web.
Selon Annie Sullivan, Software Engineer en charge du développement des métriques de performances pour Chrome, lorsqu'un site est conforme aux seuils des métriques Core Web Vitals, les utilisateurs sont 24 % moins susceptibles d'abandonner le chargement de la page.
Concentrons-nous sur la métrique qui correspond au temps de chargement.
Largest Contentful Paint (LCP) - métrique du temps de chargement
Le LCP est le temps nécessaire au navigateur pour afficher le plus grand élément visible, dans la fenêtre d'affichage, à partir du moment où l’utilisateur accède pour la première fois à la page. Il s’agit souvent d’une image ou d’une vidéo, mais cela peut aussi concerner une zone de texte trop volumineuse.
C’est donc le temps qu’attendra l’internaute pour pouvoir consulter votre page. Cette métrique indique donc le temps à partir duquel l’utilisateur constate que la page est correctement chargée. Pour une expérience de qualité, une valeur de 2,5 secondes ou moins est recommandée par Google.
Comment mesurer le LCP de mon site web ?
Plusieurs outils existent pour aider à mesurer le LCP d’un site web. Le premier est la console du navigateur, qui permet d’évaluer les timings de performance lors du chargement d’une page. Pratique pour faire des tentatives sur la machine, mais les données doivent être décortiquées à la main.
Mesure du LCP sur le site www.hokla.com avec l’outil de performance de la console Google Chrome.
Pour plus de détails et de simplicité, nous avons choisi d’utiliser Lighthouse, un outil d’audit SEO lancé par Google, que vous pouvez installer directement sur le navigateur Chrome pour générer des rapports. Le rapport comprend plusieurs résultats, dont un score de performance allant de 1 à 100. Ce score est le calcul pondéré de plusieurs métriques des signaux web essentiels, incluant le LCP.
Calculateur pondéré du score de performance Lighthouse par Google
Avec cet outil, il est possible d’évaluer le LCP d’un site web. Pour des mesures plus précises, utiliser la navigation privée et désactiver toutes les extensions de votre navigateur. De plus, l’analyse étant lancée sur votre machine, les performances de celle-ci peuvent influencer les résultats. Des alternatives comme PageSpeed Insights existent afin de générer un rapport Lighthouse en ligne.
Vrai, nous avons gagné 4s de LCP simplement en remplaçant un fond bleu CSS en tête de page par une image bleue
Maintenant que nous sommes capable de mesurer notre LCP, comment le suivre au quotidien pour s’assurer que les développements respectent les objectifs de performances SEO ?
Pour suivre les métriques Lighthouse dans le temps, nous avons implémenté une GitHub action qui lance une analyse Lighthouse en ligne de commande à intervals réguliers sur notre environnement de production. Les métriques sont ensuite extraites du rapport Lighthouse, et envoyées sur notre outil Datadog à l’aide de l’API fournie.
Grâce aux métriques reçues dans Datadog, nous avons mis en place des dashboards nous permettant de suivre nos indicateurs dans le temps, comme le LCP.
Le suivi des métriques Lighthouse nous a permis de détecter des régressions lors des développements.
Graphique montrant l’évolution du score de performance Lighthouse de toutes nos pages. On y observe une régression globale entre les 3 et 4 novembre.
Suite au passage en chargement dynamique de nos bannières en-têtes de page, nous avons observé une baisse de la performance de toutes nos pages. Il se trouve que le chargement dynamique ne doit être utilisé que pour les éléments non visibles dans le viewport de chargement initial.
En effet, le chargement dynamique s’effectue une fois tous les autres éléments chargés, quand le navigateur est disponible. Hors, nos en-têtes sont visibles dans le viewport initial, ce qui a impacté négativement les performances. Pour corriger la regression, nous avons retiré le chargement dynamique de nos bannières en-têtes, et la performance est repartie à la hausse.
Grâce à toutes ces métriques, nous avons identifié de nombreuses opportunités d’amélioration. Cela a mis en évidence que la bannière de cookies était considérée comme le plus grand élément visible sur plusieurs de nos pages : le LCP. Or cette bannière est très lente à être affichée, et elle n’est pas sensée être l’élément le plus important de la page.
Capture d’écran de la bannière en-tête bleue, sensée être le plus grand élément de la page, partiellement cachée par la bannière de cookies.
Il s’avère que les divs colorisées en CSS ne sont pas évaluées dans le calcul du LCP.
En remplaçant le fond bleu CSS par une image bleue, nous avons gagné 4 secondes de LCP du point de vue des moteurs de recherches Google, pour une expérience utilisateur intacte.
Graphique montrant l'évolution dans le temps du LCP de la page optimisée. On observe une diminution du LCP de 4s.
Comment CSSinJS nous faisait perdre 1s de temps de chargement sur toute l’application
Après avoir stabilité toute l’application sur des métriques uniformes, nous avons rapidement atteint un plafond de verre. Nous nous sommes posé la question, sommes-nous capable d’améliorer davantage les performances globales de l’application ?
Nous avons cherché dans le code les éléments qui étaient présent sur chaque page : le style. Est-ce qu’on utilise la méthode la plus performance d’un point de vue SEO technique ? La réponse était non.
Nous utilisons le CSSinJS. En creusant chez nos fournisseurs, la librairie Mantine, nous avons lu que dans le patch note de la version 7, la librairie a abandonné le CSSinJS pour du CSS natif, avec comme argument le coût en performance du CSSinJS : “Ce changement améliore les performances et réduit la taille du bundle de la librairie”. Nous avons appris deux choses :
- Le CSSinJS est appliqué côté client et demande des ressources au navigateur pour être calculé. Chaque seconde accordée par le navigateur au rendu du CSSinJS est une seconde qui n’est pas allouée au chargement du LCP.
- Le CSSinJS augmente la taille du bundle javascript qui est téléchargé par le navigateur. Dans la même logique, chaque seconde passée à télécharger le CSSinJS n’est pas exploitée pour le LCP.
Schéma montrant la différence observée sur le temps de chargement entre les pages en CSSinJS (Mantine) et les pages en SCSS. Gain de 1s pour le SCSS.
Pour améliorer nos temps de chargements, nous avons décidé de migrer tout notre code du CSSinJS en CSS. Et pour ne pas perdre en fonctionnalités (thème, fonctions, …), nous avons choisi d’utiliser le SCSS. Ça nous permet de travailler avec des CSS modules, d’avoir toutes les optimisations en performance du préprocesseur SCSS et du cache efficace. Nous réduisons ainsi le temps que passe le navigateur à gérer le style sur nos pages, ce qui améliore les temps de chargement.
Concrètement, ça ressemble à ça pour un composant simple.
Before the migration (CSSinJS)
After the migration (SCSS)
Avec cette migration sur l’ensemble de nos composants et pages, nous avons gagné 1s de temps de chargement sur toute l’application. Pour en savoir plus ce changement, consultez l'article Why We're Breaking Up with CSS-in-JS.
Maintenant, vous savez ! Enfin presque
En plaçant l'expérience et la satisfaction de l'utilisateur au premier plan, nous avons souligné que la qualité d'un site constitue la fondation essentielle pour des performances SEO optimales. En créant un environnement web fluide et rapide, les sites gagnent la confiance des utilisateurs, favorisant ainsi des classements plus élevés sur les moteurs de recherche.
En conclusion, notre exploration du SEO technique nous a conduit à comprendre l'importance des Core Web Vitals dans l'évaluation de la performance d'un site web. Nous avons également exploré la nécessité de remettre en question les choix technologiques, comme le CSSinJS.
Une dimension souvent négligée, mais cruciale, est l'impact des scripts tiers sur l’expérience utilisateur, dégradant le temps de chargement des pages et les signaux web essentiels. Bien que certains scripts tiers soient nécessaires pour enrichir l'expérience utilisateur, il est impératif de les gérer avec soin. Des solutions ingénieuses, telles que PartyTown pour Google Tag Manager, peuvent réduire significativement le LCP, apportant ainsi des améliorations tangibles à l'expérience utilisateur.
Mais rappelons que la vitesse n’est pas le seule critère d’évaluation de l’expérience utilisateur. Tandis que le temps de chargement permet d'accueillir l'utilisateur dans un monde numérique sans délai, l'accessibilité, qui est souvent négligée, s'efforce de faire en sorte que chaque individu, quels que soient ses besoins ou capacités, puisse pleinement participer à cette expérience.
Avez-vous déjà exploré votre site en utilisant un lecteur d'écran pour mettre à l’épreuve son expérience utilisateur ? Faites le test : NV Access (Windows) et VoiceOver (macOS).
.png)
