Vérifier la vitesse d’un blog : comprendre LCP, INP et CLS

Pour vérifier la vitesse d’un blog, analysez une adresse publique dans PageSpeed Insights, comparez mobile et ordinateur et examinez LCP, INP et CLS pour le chargement, la réactivité et la stabilité visuelle. Distinguez les données réelles des diagnostics de laboratoire. Corrigez ensuite la cause d’une mauvaise mesure plutôt que de viser seulement un score global.

Que mesurent LCP, INP et CLS ?

Les Core Web Vitals sont les indicateurs essentiels de Google pour l’expérience Web. L’ensemble actuel comprend les trois mesures suivantes. Une valeur plus faible est préférable pour chacune, mais leurs objets et unités diffèrent.

Le guide Web Vitals utilise le 75e centile, séparément sur mobile et ordinateur : environ 75 % des observations se situent à cette valeur ou en dessous. Ce n’est ni une moyenne ni le meilleur essai isolé. Lorsque les trois mesures ont assez de données, elles doivent toutes être bonnes pour réussir l’évaluation ; un bon LCP seul ne suffit pas.

Une page peut apparaître vite mais réagir lentement à l’ouverture du menu. Une autre répond correctement mais pousse le texte quand une publicité arrive. Identifiez l’expérience dégradée avant de compresser encore les images pour résoudre un problème de « vitesse » mal défini.

Lancer une analyse PageSpeed Insights

1. Choisissez un article accessible sans connexion, pas une URL d’éditeur ou d’aperçu.
2. Saisissez son adresse dans PageSpeed Insights et lancez l’analyse.
3. Dans le résultat mobile, séparez expérience réelle des utilisateurs et diagnostic de performance.
4. Consultez aussi l’ordinateur. Notez adresse, date, catégorie d’appareil, mauvaises mesures et principales observations.

Ne vérifiez pas seulement le dernier article. Choisissez des formats représentatifs : texte courant, contenu riche en images et page avec tableaux ou code, si votre blog en contient. Vous distinguerez plus facilement un défaut du modèle commun d’un défaut propre au contenu.

Vérifiez aussi si l’adresse analysée diffère de celle saisie. Si une redirection mène ailleurs, reprenez cette destination finale pour les comparaisons ultérieures. Des relevés cohérents servent à juger les changements, pas simplement à améliorer le score affiché.

Distinguer données de terrain et score de performance

Les données d’utilisateurs proviennent du Chrome User Experience Report (CrUX) sur les 28 derniers jours. Si l’échantillon est insuffisant, le résultat peut afficher les données de l’origine entière ou aucune donnée de terrain. Le diagnostic de laboratoire utilise Lighthouse dans un environnement simulé. La documentation de PageSpeed Insights explique cette différence.

Un score de performance de 90 et une réussite Core Web Vitals réelle sont deux évaluations distinctes. Contrôlez si les données concernent l’URL ou l’origine. Leur absence ne certifie ni une bonne performance ni un problème.

La période glissante CrUX et l’essai Lighthouse actuel reposent sur des conditions et échantillons différents. Le schéma sépare leurs preuves et leur usage pour décider quoi comparer après une modification.

Remplacer une image peut améliorer immédiatement un résultat de laboratoire alors que la période réelle comprend encore des visites antérieures. Vérifiez d’abord le bon chargement du nouveau fichier et les signes d’amélioration dans des essais comparables. Suivez séparément la tendance réelle dans le temps.

Une valeur INP absente ne signifie pas zéro milliseconde. PSI peut réussir l’évaluation avec des données INP insuffisantes si LCP et CLS ont tous deux un bon 75e centile ; des données insuffisantes pour LCP ou CLS empêchent l’évaluation. Les règles d’évaluation PSI précisent cette exception. Lisez les données présentes en plus de l’étiquette de réussite.

LCP dégradé : trouver ce qui retarde le contenu principal

Identifiez d’abord l’élément déclaré comme le plus grand contenu : image supérieure, bloc de texte ou autre. N’appliquez pas partout le même réglage d’image sans savoir quel élément est mesuré.

• Pour une image, comparez ses dimensions transférées à ses dimensions d’affichage.
• Adaptez dimensions, compression et format en préservant détails nécessaires et lisibilité du texte.
• Vérifiez si l’image LCP du premier écran est chargée en différé. Utile plus bas, ce réglage peut retarder l’image principale.
• Si le diagnostic signale réponse serveur ou ressources bloquant le rendu, examinez aussi ces causes.

Le guide d’optimisation LCP sépare découverte, transfert et affichage du contenu. Si un autre format convient, consultez la conversion d’images en WebP. Si l’ancien fichier est encore servi, contrôlez le cache et la ressource réellement demandée.

Développez la décomposition LCP pour repérer où le temps est passé, puis ciblez le délai important ou évitable :

1. Time to First Byte (TTFB) : temps de la navigation au premier octet de réponse HTML. Examinez serveur, chaînes de redirections et cache.
2. Délai avant chargement de la ressource : attente entre cette réponse et le début du téléchargement de l’image principale ou autre ressource LCP. Vérifiez découverte tardive et chargement différé.
3. Durée de chargement de la ressource : téléchargement proprement dit. Dimensions et compression adaptées agissent directement ici.
4. Délai de rendu : attente d’affichage après réception du fichier. Scripts et conditions d’affichage peuvent encore bloquer ; réduire le fichier peut donc ne pas améliorer le LCP total.

Un élément LCP textuel sans téléchargement de ressource distinct peut ne pas avoir de phase de chargement de ressource. Appliquez cette décomposition à l’élément réellement identifié.

INP dégradé : examiner le travail après l’interaction

L’INP mesure la réactivité jusqu’à la prochaine mise à jour visuelle. De longues tâches JavaScript peuvent occuper le fil principal du navigateur, chargé des scripts et de l’affichage, et retarder le traitement de la saisie. Le guide d’optimisation INP distingue délai d’entrée, traitement de l’événement et délai de présentation.

Commencez par reproduire des actions courantes sur mobile : ouvrir le menu, rechercher et utiliser la table des matières. Notez l’action lente et examinez les extensions, widgets et scripts externes inutiles ou en double sur cette page.

Le Total Blocking Time (TBT) d’un essai Lighthouse de chargement peut signaler de longues tâches, mais ce n’est pas l’INP. Ce dernier demande clic, toucher ou clavier ; une visite sans interaction ou limitée au défilement peut ne pas avoir de valeur. Distinguez aussi le premier retour visuel après Recherche, comme un indicateur de chargement, de la fin de toute la recherche serveur. La définition de l’INP précise son périmètre.

Ne désactivez pas de nombreuses extensions ensemble. Préparez sauvegarde ou environnement d’essai et changez un point à la fois pour identifier son effet. Si vous retardez l’exécution JavaScript, contrôlez aussi menus, recherche et consentement, en plus du score.

CLS dégradé : réserver l’espace des contenus qui arrivent tard

Images, publicités et contenus intégrés tardifs peuvent pousser le texte ou le lien que l’on s’apprête à toucher. Le guide CLS insiste sur les dimensions d’images et l’espace réservé aux contenus tardifs.

• Fournissez width et height ou un rapport de dimensions réservé adapté.
• Prévoyez un espace publicitaire ou vidéo approprié à chaque taille d’écran.
• Évitez qu’un emplacement publicitaire vide se referme brusquement et crée un nouveau déplacement.
• Observez les mouvements de texte et boutons lors de l’arrivée des polices et bandeaux.

L’élément signalé comme déplacé n’est pas nécessairement la cause. Une publicité insérée au-dessus peut faire enregistrer le déplacement de l’article situé dessous. Inspectez le voisinage et les ajouts précédents. Un essai initial peut aussi manquer les mouvements après défilement : parcourez l’article public et testez menus et consentement.

Réduire les espaces vides et stabiliser la page peut demander un compromis. Une hauteur publicitaire d’ordinateur ne convient pas forcément au mobile. Ouvrez de vrais articles et examinez les mouvements dans le haut, le milieu et le bas de l’écran.

Recontrôler dans des conditions comparables

1. Conservez réglages, fichiers et résultats initiaux.
2. Choisissez une cause importante et effectuez une modification ciblée.
3. Actualisez les caches concernés et vérifiez la ressource modifiée sur la page publique.
4. Retestez la même URL et la même catégorie d’appareil, puis contrôlez menus, images, publicités et mise en page.
5. En cas de fonction cassée ou d’autre mesure dégradée, restaurez le changement et précisez le diagnostic.

Dans les réglages de cache, distinguez service de ressources enregistrées et report d’exécution des scripts. Le guide des extensions de cache WordPress explique leur rôle. Gardez les valeurs à rétablir plutôt que d’activer plusieurs optimisations en même temps.

Un petit écart sur un seul essai ne démontre pas une réussite. Comparez relevés et problèmes récurrents avant la modification suivante. Un meilleur score obtenu en cassant une fonction utile n’améliore pas la lecture.

Le score de vitesse ne détermine pas seul la visibilité dans la recherche. Les consignes Google sur l’expérience de page indiquent l’usage des Core Web Vitals dans les systèmes de classement sans promettre les premières places. Améliorez aussi la possibilité de lire et d’accomplir des actions utiles.