Vitesse et mobile :ce qu'il faut mesurer et où cela cesse de rapporter

Les trois valeurs en langage ordinaire

LCP, largest contentful paint. Le temps qu'il faut pour que le plus grand bloc de texte ou la plus grande image soit à l'écran. C'est le moment où un visiteur se dit : la page est là. Pas le moment où tout est terminé. Les coupables habituels sont une image d'en-tête énorme qui n'a pas été réduite, un serveur lent et une bannière de cookies qui retient tout derrière elle.

CLS, cumulative layout shift. L'ampleur des sauts de la page sous votre doigt pendant qu'elle charge. Vous voulez cliquer sur un lien et au dernier moment une publicité ou une bannière se glisse entre les deux, si bien que vous touchez autre chose. C'est le CLS. La cause est presque toujours la même : des images ou des iframes sans hauteur ni largeur indiquées. Une deuxième cause est un élément inséré plus tard dans la page.

INP, interaction to next paint. Le temps qu'il faut pour que la page réagisse visiblement après que vous avez cliqué ou appuyé sur quelque chose. Un menu qui ne s'ouvre qu'après une seconde, un bouton qui semble ne rien faire. L'INP a remplacé en mars 2024 l'ancienne mesure FID et il mesure plus sévèrement, car il regarde toute la réaction plutôt que le premier retard. La cause est généralement trop de JavaScript qui tourne en même temps.

Les seuils

Entre bon et mauvais se trouve une zone intermédiaire que Google désigne comme à améliorer. Deux remarques sur ce tableau.

D'abord : la mesure se fait au 75e centile. Trois visiteurs sur quatre doivent se situer sous le seuil. Votre propre ressenti sur un portable rapide en fibre ne dit donc rien. Le visiteur qui compte est celui avec un téléphone de trois ans sur une connexion moyenne.

Ensuite : ces seuils ne sont pas gravés dans la pierre. Google a déjà modifié l'ensemble par le passé et peut le refaire. Contrôlez les valeurs actuelles à la source avant de les inscrire dans un cahier des charges ou dans un contrat.

Données de laboratoire et données de terrain : c'est là que presque tout le monde bloque

C'est la distinction qui rend inutile la plupart des discussions sur la vitesse des pages.

Les données de laboratoire sont une mesure dans un environnement contrôlé. Un appareil, une connexion simulée, un moment. Lighthouse et la partie laboratoire de PageSpeed Insights font cela. Avantage : reproductible et cela dit exactement ce qui ne va pas. Inconvénient : ce n'est pas votre public.

Les données de terrain proviennent de vrais utilisateurs de Chrome qui ont visité votre site, rassemblées sur une période de 28 jours. Cela s'appelle le Chrome User Experience Report. Le rapport Core Web Vitals dans la Search Console montre ces chiffres. Avantage : c'est la réalité et c'est ce qui compte pour votre position. Inconvénient : cela traîne derrière et vous ne voyez l'effet d'une amélioration que des semaines plus tard.

Deux conséquences que vous devez connaître. Un petit site a souvent trop peu de visiteurs pour les données de terrain. La Search Console signale alors que les données sont insuffisantes. Ce n'est pas une erreur ni un problème, c'est une conséquence de votre nombre de visiteurs. Vous travaillez alors avec les données de laboratoire et avec du bon sens.

Et l'INP ne se mesure pas correctement en laboratoire, car il n'y a personne qui clique. Lighthouse donne à la place le total blocking time comme approximation. Celui qui vous présente un chiffre d'INP issu d'un test de laboratoire mesure autre chose que ce qu'il annonce.

Faire tourner Lighthouse en local, gratuitement

Vous n'avez besoin d'aucun outil payant pour cela ni d'aucun compte.

1. Ouvrez la page dans Chrome.
2. Clic droit puis Inspecter. Le raccourci est F12 sous Windows et Cmd+Option+I sur Mac.
3. Choisissez l'onglet Lighthouse. S'il n'y figure pas, cliquez sur la double flèche à côté des onglets.
4. Mettez l'appareil sur Mobile et cochez Performances.
5. Cliquez sur Analyser le chargement de la page.

Trois règles pratiques. Lancez le test dans une fenêtre de navigation privée, sinon vous mesurez aussi vos propres extensions de navigateur. Lancez-le trois fois et retenez le résultat du milieu, car le score varie entre deux mesures identiques. Et ne testez pas seulement la page d'accueil. Les pages par lesquelles vos visiteurs entrent sont plus importantes et c'est rarement la page d'accueil.

Si vous voulez les données de terrain et celles de laboratoire côte à côte, utilisez PageSpeed Insights sur le web. En haut figurent les données de terrain s'il y en a, en dessous la mesure de laboratoire. Ne confondez pas les deux blocs, car ils se suivent et mesurent autre chose.

Mobile : viewport et zoom

Google indexe le mobile d'abord. Ce qui ne figure pas dans la version mobile de votre page ne compte pas. Un site qui cache la moitié du texte sur mobile cache aussi cette moitié à Google.

Une ligne de HTML est obligatoire dans le <head> de chaque page :

<meta name="viewport" content="width=device-width, initial-scale=1">

Sans cette ligne, un téléphone montre votre page comme une version bureau dézoomée et le visiteur doit zoomer pour lire quoi que ce soit.

Ce que vous n'y ajoutez pas : user-scalable=no ou maximum-scale=1. Ces deux réglages bloquent le zoom. C'est un problème pour toute personne qui voit moins net et c'est une faute d'accessibilité. Certains navigateurs ignorent désormais ce réglage. N'y comptez pas et laissez-les simplement de côté.

Trois choses qui reviennent encore sur mobile :

• Un texte trop petit. Sous 16 pixels, la lecture sur un téléphone devient pénible. Dans les champs de saisie, cela a une conséquence supplémentaire : iOS zoome automatiquement quand la taille de police est inférieure à 16 pixels, ce qui éjecte le visiteur de la mise en page.
• Des cibles tactiles trop proches. Deux liens l'un sous l'autre avec quelques pixels d'écart ne se séparent pas avec un doigt.
• Le défilement horizontal. Un tableau ou une image plus large que l'écran fait basculer toute la page. Lighthouse le signale sous la rubrique indiquant que le contenu n'est pas correctement dimensionné.

Où cela cesse de rapporter

Voici la partie honnête. La vitesse est un signal de positionnement au poids limité. Elle agit surtout comme arbitre entre des pages équivalentes sur le fond. Une page plus lente avec une meilleure réponse bat une page rapide avec une mauvaise réponse.

De cinq secondes à deux secondes, la différence est perceptible, pour le visiteur et pour la mesure. De 1,4 seconde à 1,2 seconde, elle ne l'est pas. Ce qu'un dixième de seconde rapporte exactement en chiffre d'affaires n'est pas connu de manière fiable pour votre site. Ce qui est établi, c'est l'endroit où se situe le seuil : 2,5 secondes pour le LCP et non zéro. Si vous êtes en dessous, ce sujet est clos et votre prochaine journée de travail est mieux employée au contenu.

Celui qui continue malgré tout à chasser un score Lighthouse de 100 le paie généralement avec autre chose. Un module de chat à supprimer, du tracking à supprimer, une police à supprimer. Parfois c'est le bon arbitrage. Souvent c'est optimiser un score plutôt qu'un site.

Là où le gain se trouve bel et bien pour une PME, dans cet ordre :

1. Les images. Des fichiers trop lourds sont la cause la plus fréquente d'un mauvais LCP. Réduisez à la taille d'affichage, enregistrez en WebP et ne faites charger les images sous la ligne de flottaison que lorsqu'elles sont nécessaires.
2. Les scripts que vous n'utilisez pas. Une fenêtre de chat, trois pixels de suivi, un tag manager avec des règles oubliées et un plugin de carrousel de 2019. Chaque script coûte de l'INP.
3. La bannière de cookies. Elle est souvent responsable à la fois du pire LCP et du pire CLS, parce qu'elle charge par-dessus la page et pousse le reste vers le bas.
4. La mise en cache et la compression chez votre hébergeur. Généralement un interrupteur dans le panneau de configuration de votre hébergement.
5. Des dimensions fixes sur les images et les iframes. Deux attributs, width et height, résolvent la majeure partie des problèmes de CLS.

Ce que vous pouvez faire vous-même et ce que vous ne pouvez pas

À faire vous-même, sans développeur :

• Lancer Lighthouse dans Chrome et ouvrir le rapport Core Web Vitals dans la Search Console.
• Réduire les images avant de les téléverser. C'est le gain le moins cher de tout ce chapitre.
• Désactiver les plugins et les scripts que plus personne n'utilise.
• Contrôler la ligne viewport et retirer user-scalable=no s'il y figure.
• Activer la mise en cache et la compression chez votre hébergeur.

Ce pour quoi vous avez besoin d'aide :

• Une réponse serveur lente. Si le premier octet arrive déjà tard, cela tient à votre hébergement ou à la construction du site. Ce n'est pas un réglage.
• Du CSS et du JavaScript qui bloquent le dessin de la page. Les réorganiser demande de connaître le thème.
• Un site entièrement construit en JavaScript. Là, la vitesse et la visibilité sont une seule et même question de construction et cela ne se résout pas avec un plugin.
• Un thème lourd par conception. À un certain point, remplacer revient moins cher que réparer.

Notre ordre de travail : mesurer d'abord, parcourir ensuite les cinq points ci-dessus, puis mesurer à nouveau. Si vous restez au-dessus des seuils après cela, c'est une conversation sur l'hébergement ou sur le thème et non plus sur des réglages.

Vous préférez ne pas le faire vous-même : SEMANU réalise l'audit SEO et GEO complet pour 1 450 euros, rapport et séance de travail compris. Le détail figure sur la page du guide.