Les pages rapides se classent mieux. Sachez lesquelles sont lentes.

Les Core Web Vitals sont trois indicateurs qui décrivent le ressenti d’un visiteur sur une page :

• Largest Contentful Paint (LCP) : le temps nécessaire pour que le contenu principal, en général l’image du haut de page ou le premier bloc de texte, soit visible. Bon : 2,5 s ou moins.
• Interaction to Next Paint (INP) : la rapidité avec laquelle la page réagit quand quelqu’un touche, clique ou tape. Bon : 200 ms ou moins. L’INP a remplacé le First Input Delay en mars 2024.
• Cumulative Layout Shift (CLS) : l’ampleur des sauts du contenu pendant le chargement. Bon : 0,1 ou moins.

Le test des Core Web Vitals qui compte est celui que Google mène sur les vrais visiteurs : il regarde le 75e centile des visites des 28 derniers jours, séparément sur mobile et sur ordinateur. Une page le réussit quand les trois indicateurs sont bons à ce centile.

« En combien de secondes ma page doit-elle se charger ? » Il n’y a pas de réponse unique, car une page n’est jamais chargée à un instant précis : les premiers octets arrivent, puis le contenu principal, puis les images plus bas, puis les scripts qui la rendent interactive. Les seuils des Core Web Vitals découpent la question en étapes qui correspondent à ce que remarquent les visiteurs :

• Réponse du serveur (TTFB) : moins de 0,8 seconde. Ce n’est pas un Core Web Vital, mais tout le reste l’attend.
• Contenu principal visible (LCP) : en 2,5 secondes au plus.
• Réaction à un toucher ou un clic (INP) : en 200 millisecondes au plus.
• Mise en page stable (CLS) : un décalage de 0,1 ou moins.

Visez ces seuils sur mobile d’abord, pour au moins trois visites réelles sur quatre.

Un test de vitesse de site internet comme PageSpeed Insights charge votre page une fois, sur un téléphone milieu de gamme simulé avec une connexion bridée. Ce sont des données de laboratoire : assez reproductibles pour déboguer, mais il s’agit d’une seule visite dans des conditions artificielles. Le Chrome UX Report collecte des données de terrain auprès de vrais utilisateurs de Chrome qui l’ont accepté, et ce sont elles que Google utilise.

Les deux divergent souvent. Une page peut obtenir 60 en laboratoire et valider les Core Web Vitals sur le terrain parce que la plupart des visiteurs ont des téléphones rapides, ou l’inverse. Les tests de laboratoire ne peuvent pas non plus mesurer l’INP, puisque personne n’interagit avec la page ; le Total Blocking Time est l’indicateur de laboratoire le plus proche.

LCP : suivre la chaîne de chargement

Le LCP est le signal le plus lent sur la plupart des sites. Remontez la chaîne de chargement dans l’ordre :

1. 1Réduisez le temps de réponse du serveur : mettez le HTML en cache quand c’est possible et gardez le délai avant le premier octet bien sous la seconde.
2. 2Rendez l’élément LCP léger et précoce : servez l’image principale en AVIF ou WebP à sa taille d’affichage, et ne la chargez pas en différé.
3. 3Supprimez les ressources qui bloquent l’affichage : intégrez le CSS critique dans la page et différez les scripts inutiles au premier affichage.
4. 4Évitez de générer le contenu principal en JavaScript quand le serveur pourrait l’envoyer en HTML.

INP : libérer le thread principal

Des interactions lentes signifient presque toujours trop de JavaScript exécuté au mauvais moment. Supprimez les scripts inutilisés, chargez plus tard les balises tierces comme les widgets de chat et les traceurs, découpez les tâches longues en tâches plus courtes et évitez les traitements lourds dans les gestionnaires de clic.

CLS : réserver l’espace

Donnez à chaque image et vidéo des attributs de largeur et de hauteur, réservez l’espace des bannières, publicités et contenus intégrés avant leur chargement, et chargez les polices web de sorte que la police de secours ait des dimensions proches. Un contenu inséré au-dessus de ce que le visiteur est en train de lire est la cause classique d’un mauvais CLS.

Les problèmes de vitesse se logent en général dans les gabarits, pas dans des pages isolées. Testez une ou deux pages de chaque gabarit : la page d’accueil, une catégorie, un produit, un article, une page d’atterrissage. Corrigez ensuite les gabarits qui portent le plus de trafic de recherche, que vous lisez dans les clics de la Google Search Console.

Une page lente que personne ne visite peut attendre ; un gabarit produit lent qui apporte la moitié de votre chiffre d’affaires organique, non. L’audit de site classe les pages lentes avec les liens cassés et les problèmes d’indexation selon le trafic qu’elles portent.

La vitesse régresse sans bruit : une nouvelle balise de suivi, une image de haut de page plus lourde ou la mise à jour d’une extension peuvent annuler des mois de travail. Une routine hebdomadaire le détecte tôt :

• Testez de nouveau vos pages clés sur mobile et sur ordinateur chaque semaine.
• Surveillez les données de terrain sur 28 jours du site et de chaque page clé, et recevez une alerte quand un signal passe en « mauvais ».
• Comparez les Core Web Vitals de vos vrais visiteurs à ceux de vos concurrents, puisque c’est face à eux que vous êtes classé.
• Vérifiez la tendance hebdomadaire après chaque mise en production.

Aseoma fait les quatre. Il choisit vos pages clés à partir des clics de la Search Console et de votre dernier audit, les teste chaque semaine avec PageSpeed Insights, conserve l’historique du Chrome UX Report pour le site et pour chaque page, affiche jusqu’à cinq concurrents à côté de vous et vous alerte quand un signal passe en « mauvais ». Commencez par l’audit SEO gratuit, ou consultez les offres.