Les Core Web Vitals sont trois mesures permettant d'évaluer des aspects importants de l'expérience utilisateur d'un site Web : la vitesse de chargement, la réactivité et la stabilité visuelle.
Les trois Core Web Vitals actuels s'appellent Plus grand élément affiché (LCP), Interaction to Next Paint (INP) et Déplacement cumulé de la mise en page.
Cependant, une bonne valeur à elle seule ne signifie pas nécessairement que l'ensemble du site Web fonctionne rapidement et sans problème. Chacune des trois mesures examine un aspect différent de l'expérience utilisateur.
Dans cet article, nous t'expliquons ce que mesurent le LCP, l'INP et le CLS, quelles valeurs sont considérées comme bonnes et comment rechercher systématiquement la cause en cas de résultats anormaux.
En bref : Pour faire simple, le LCP mesure la rapidité avec laquelle le contenu principal d'une page devient visible. L'INP évalue la réactivité du site web face aux interactions des utilisateurs. Le CLS mesure les changements de mise en page inattendus lors de l'utilisation.
Qu'est-ce que les Core Web Vitals ? #
Les Core Web Vitals sont des métriques définies par Google pour évaluer certains aspects de l'expérience utilisateur réelle d'une page Web.
Les trois Core Web Vitals actuels sont :
| Valeur mesurée | Nom complet | Évalué |
|---|---|---|
| LCP | Plus grand élément affiché | Expérience de recharge |
| INP | Interaction to Next Paint | Réactivité |
| CLS | Changement de disposition cumulé | Stabilité visuelle |
Les valeurs se complètent, car un site web peut être très bon dans un domaine et problématique dans un autre.
Aperçu des valeurs limites #
Google divise les valeurs en trois catégories : „ bon “, „ à améliorer “ et „ mauvais “.
| Valeur mesurée | Bien | À améliorer | Mauvais |
|---|---|---|---|
| LCP | ≤ 2,5 s | de 2,5 s à 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | 200 ms à 500 ms | > 500 ms |
| CLS | ≤ 0,1 | > 0,1 à 0,25 | 0,25 |
Important : Chacun de ces seuils correspond à un indicateur spécifique. Par exemple, un seuil LCP de 2,5 secondes ne signifie pas que tout autre temps de chargement imaginable doit également être inférieur à 2,5 secondes.
Pourquoi le 75e percentile est-il utilisé ? #
Lors de l'évaluation des données d'utilisation réelles, on ne se contente pas de regarder le meilleur ou le chargement de page moyen.
Le 75e centile est utilisé pour les Core Web Vitals.
En résumé, cela signifie que 75 pour cent au moins des expériences mesurées doivent atteindre le seuil respectif ou être meilleures.
100 expériences mesurées
75 ou plus
→ bonne plage
si la valeur au 75e centile
se situe dans la bonne limiteCela évite que l'évaluation ne dépende uniquement des appareils et des connexions particulièrement rapides.
Réussir les Core Web Vitals : qu'est-ce que cela signifie ? #
Pour obtenir un bon score Core Web Vitals, les trois indicateurs clés LCP, INP et CLS doivent se situer dans la plage de valeurs recommandées au 75e percentile, sur la base d'un volume de données suffisant.
Ainsi, un site Web peut, par exemple, avoir de bons LCP et CLS, mais échouer à l'évaluation des Core Web Vitals en raison d'un mauvais INP.
LCP → bon
INP → mauvais
CLS → bon
Résultat :
Core Web Vitals non validés entièrementLCP – Le plus grand élément peint #
Le Largest Contentful Paint mesure le temps écoulé jusqu'au rendu du plus grand élément de contenu pertinent dans la zone visible.
Cela permet au LCP de déterminer approximativement à quel moment une partie essentielle du contenu principal est devenue visible pour le visiteur.
Un bon LCP est de :
2,5 secondes ou moins
Quel élément peut être l'élément LCP ? #
Cela dépend de la structure de chaque page.
Il s'agit par exemple souvent de :
grande image principale
grand titre de texte
bannière
grande image de contenu
grand bloc de texteTu devrais vérifier quel élément est réellement détecté comme LCP à l'aide d'un outil de performance et ne pas te fier uniquement au design.
Exemple de LCP #
Supposons qu'une page d'accueil possède une grande image hero dans sa partie supérieure :
┌─────────────────────────────────────┐
│ Navigation │
├─────────────────────────────────────┤
│ │
│ GRANDE IMAGE HERO │
│ │
│ Hébergement web pour les PME │
│ │
└─────────────────────────────────────┘Si cette image constitue le plus grand élément pertinent dans la zone visible, elle peut devenir l'élément LCP.
S'il se charge tard, cela peut également dégrader le LCP.
Qu'est-ce qui peut provoquer un mauvais LCP ? #
Un LCP insuffisant peut avoir différentes causes.
Cela peut par exemple inclure :
- un déploiement lent du document HTML,
- une très grande image LCP,
- une ressource d'image découverte tardivement,
- ressources bloquant le rendu,
- Polices web,
- Rendu côté client,
- une priorisation de charge défavorable.
La cause réelle doit être examinée sur le site en question.
En cas de mauvais LCP, identifier d'abord l'élément LCP #
Avant de modifier les paramètres de performance, tu dois déterminer quel élément est mesuré.
LCP mauvais
↓
Identifier l'élément LCP
↓
Image ?
Texte ?
Autre élément ?
↓
Examiner le chemin de chargement de cet élémentGoogle PageSpeed Insights peut fournir lors de l'analyse des indications sur l'élément LCP et son comportement de chargement.
Nous vous expliquons comment utiliser l'outil sous Comment utiliser correctement Google PageSpeed Insights.
Si une image est l'élément LCP #
Si une image principale ou une image de contenu est responsable du LCP, vous devez d'abord vérifier ses propriétés techniques.
Sont intéressants, entre autres :
Dimensions en pixels
Taille du fichier
Format d'image
Compression
Variantes d'image responsives
Date de découverte
Priorité de chargement
Chargement différéUne image située dans la zone immédiatement visible ne devrait par exemple pas être traitée de la même manière, sans vérification, qu'une image située tout en bas de la page.
Nous expliquons comment préparer judicieusement des images sous Optimiser les images pour le Web : taille de fichier, format et référencement.
Le chargement différé (lazy loading) peut poser problème pour le LCP. #
Le chargement différé est souvent judicieux pour les images situées en dehors de la zone immédiatement visible.
Cependant, si le chargement d'une image LCP importante dans la partie supérieure de la page est inutilement retardé, cela peut dégrader le LCP.
C'est pourquoi il n'est pas vrai que :
Toutes les images = Lazy Loading
Mais plutôt :
Implémenter le chargement différé là où il est pertinent.
Un format d'image moderne ne suffit pas à résoudre un mauvais LCP #
WebP ou AVIF peuvent aider à réduire la taille de fichier d'une image. Cependant, le format ne représente qu'une partie du processus de chargement global.
Une image WebP géante aux dimensions de pixels inutiles peut continuer à poser problème.
Même un petit fichier image peut se charger tardivement si le navigateur le découvre tardivement.
Nous abordons le choix du format d'image sous WebP, AVIF, JPG et PNG : quel format d'image utiliser ?.
La réponse du serveur peut influencer le LCP #
Avant que le navigateur puisse rendre le contenu important de la page, il doit d'abord recevoir les données nécessaires.
Si la mise à disposition du document HTML prend déjà beaucoup de temps, le moment où les ressources en aval peuvent être découvertes et affichées s'en trouve également repoussé.
Un mauvais LCP ne doit donc pas être considéré exclusivement comme un „ problème d'image “.
INP – Interaction to Next Paint #
Interaction to Next Paint mesure la réactivité d'une page aux interactions des utilisateurs.
Cela inclut, par exemple, les interactions via :
Clic de souris
Écran tactile
ClavierL'INP mesure le temps nécessaire pour traiter une interaction et permettre au navigateur d'afficher une mise à jour visuelle.
Un bon INP est inférieur à :
200 millisecondes ou moins
Que signifie l'INP pour un visiteur ? #
Imagine que tu cliques sur un bouton.
Sur un site web réactif, vous obtenez pratiquement immédiatement une réaction visible.
En revanche, en cas de mauvaise réactivité, un retard sensible peut se produire :
Clic
↓
........ Délai ........
↓
Réaction visibleC'est précisément ce type d'expérience utilisateur que l'INP doit permettre de mesurer.
INP ne se limite pas à mesurer le premier clic #
L'INP examine les interactions lors de la visite d'une page et tente d'évaluer la réactivité globale à l'aide d'une interaction lente représentative.
Il ne s'agit donc pas simplement d'une mesure de la première interaction après le chargement de la page.
Qu'est-ce qui caractérise la latence d'interaction ? #
De manière simplifiée, la durée d'une interaction peut se décomposer en plusieurs étapes :
Interaction utilisateur
↓
Délai de saisie
↓
Gestionnaire d'événements / Traitement
↓
Délai de rendu
↓
prochaine image visibleDes problèmes peuvent survenir dans différentes parties de ce processus.
Qu'est-ce qui peut provoquer un mauvais INP ? #
Une cause fréquente est une charge de travail excessive sur le thread principal du navigateur.
Cela peut être dû à un code JavaScript volumineux ou inefficace.
D'autres causes possibles sont, par exemple :
- longues tâches JavaScript,
- gestionnaires d'événements complexes,
- modifications complexes du DOM,
- importants travaux de mise en page et de rendu,
- plusieurs scripts exécutés simultanément,
- code tiers complexe.
Qu'est-ce que le thread principal ? #
Le thread principal, ou main thread, du navigateur assume de nombreuses tâches nécessaires à l'affichage et à l'interactivité d'une page web.
Cela comprend entre autres des parties de l'exécution de JavaScript, des calculs de mise en page et des travaux de rendu.
Si ce fil de discussion est occupé par une tâche pendant une longue période, il ne peut pas répondre immédiatement à une nouvelle interaction utilisateur en même temps.
Fil principal :
████████ long exercice JavaScript ████████
↓
L'utilisateur clique ici
↓
doit d'abord patienterQue sont les "Long Tasks" ? #
Des tâches longues sur le thread principal peuvent nuire à la réactivité d'un site web.
Une tâche JavaScript volumineuse peut par exemple occuper le navigateur au point que les interactions de l'utilisateur soient traitées avec du retard.
Lors de l'optimisation de l'INP, il est donc souvent intéressant de savoir quelles tâches se déroulent lors d'une interaction lente.
L'INP n'est pas la même chose que le TBT #
Dans Lighthouse, vous rencontrez souvent la valeur Total Blocking Time, ou TBT en abrégé.
Le TBT est une métrique de laboratoire. L'INP, en revanche, repose sur de véritables interactions utilisateur et constitue un Core Web Vital.
Le TBT peut être utile pour le diagnostic technique, mais il ne remplace pas l'INP.
TBT
→ Mesure en laboratoire
INP
→ données d'interaction réelles possibles
→ Core Web VitalPourquoi PageSpeed ne peut-il pas générer un véritable INP lors d'un test en laboratoire ? #
L'INP nécessite de véritables interactions utilisateur lors d'une visite de page.
Un test de chargement Lighthouse synthétique ne possède pas la même collection d'interactions réelles que les données de terrain.
C'est pourquoi tu dois porter une attention particulière aux données de terrain disponibles pour l'INP.
Que faire en cas de mauvais INP ? #
Essayez d'abord de déterminer quelles interactions sont lentes.
Exemples :
Ouvrir le menu
Appliquer le filtre
Sélectionner la variante de produit
Ouvrir l'accordéon
Utiliser le formulaire
Mettre à jour le panier
Gérer la bannière de cookiesEnsuite, vous devez examiner quel travail de rendu ou quel code JavaScript est déclenché par cette interaction.
Conseil pratique : En cas de mauvais INP, vous ne devez pas simplement désactiver des fichiers JavaScript au hasard. Découvrez d'abord quelle interaction est lente et ce que le navigateur traite pendant cette interaction.
Les scripts tiers peuvent influencer l'INP #
Les sites web chargent souvent du JavaScript à partir de services externes.
Les exemples sont :
Analytique
Gestionnaire de balises
Système de chat
Widgets de médias sociaux
Systèmes publicitaires
Suivi
Cartes
Outils marketingUn tel code peut également consommer du temps de calcul sur le thread principal.
Cela ne signifie pas qu'il faille supprimer chaque service externe. Son utilité doit toutefois être mise en balance avec la complexité technique et les impacts éventuels sur les performances.
CLS – Cumulative Layout Shift #
Le Cumulative Layout Shift mesure les déplacements inattendus des éléments visibles d'une page.
Un bon CLS est de :
0,1 ou moins
Contrairement au LCP et à l'INP, le CLS n'est pas exprimé en secondes ou en millisecondes.
Il s'agit d'une valeur sans dimension qui décrit les effets des changements de mise en page inattendus.
Quel effet cela fait-il d'avoir un mauvais CLS ? #
Un exemple type :
Tu t'apprêtes à cliquer sur un bouton. Juste avant le clic, un autre élément apparaît au-dessus. Le bouton se déplace vers le bas et tu cliques par inadvertance sur autre chose.
AVANT
[ Acheter ]
Tu veux cliquer ...
↓
L'image se charge
↓
APRÈS
[ nouvelle image ]
[ Acheter ]
Le bouton s'est soudainement déplacéDe tels mouvements imprévus peuvent être très gênants.
Toute modification de mise en page n'est pas mauvaise #
Les modifications de mise en page peuvent également être attendues par l'utilisateur et déclenchées consciemment.
Par exemple, si vous ouvrez un menu ou déployez une section accordéon, l'interface doit pouvoir s'adapter en conséquence.
Ce qui pose particulièrement problème, ce sont les décalages inattendus qui surviennent sans que l'utilisateur ne s'y attende.
Qu'est-ce qui peut provoquer un mauvais CLS ? #
Les causes typiques peuvent être :
- Images sans place réservée,
- Espaces publicitaires ou bannières sans dimensions fixes,
- contenus insérés a posteriori,
- Éléments de cookies ou d'avertissement qui déplacent le contenu,
- certains effets de polices web,
- widgets dynamiques.
Images sans dimensions et CLS #
Si le navigateur ne sait pas combien d'espace est nécessaire avant de charger une image, la mise en page peut changer dès que l'image apparaît.
Pour une image HTML, par exemple, des indications appropriées pour largeur et hauteur aider à prendre en compte le rapport hauteur/largeur ou l'espace requis à l'avance.
<img
src="beispiel.webp"
width="1200"
height="800"
alt="Image d'exemple"
>Les CMS modernes intègrent souvent ce type d'informations automatiquement. En cas de CLS anormal, il est tout de même recommandé de procéder à une vérification.
Polices web et décalages de mise en page #
Les polices de caractères peuvent également influencer l'affichage.
Si une police de substitution est affichée en premier puis remplacée ultérieurement par une police web, les largeurs de caractères et les sauts de ligne peuvent changer.
Cela peut également entraîner un décalage de la mise en page.
Il faudrait mesurer, et non pas seulement supposer, si cela provoque réellement un problème de CLS pertinent.
Bandeau de cookies et CLS #
Une bannière de cookies peut également provoquer des décalages de mise en page si elle est insérée ultérieurement dans le flux normal de la page et déplace le contenu existant.
Un overlay qui apparaît par-dessus le contenu existant se comporte techniquement différemment d'un élément qui prend de la place dans la mise en page de manière séquentielle.
En cas de valeurs CLS anormales, tu dois donc également examiner les systèmes de consentement et d'information.
Contenu dynamique et CLS #
Le contenu chargé ultérieurement peut poser problème si aucun espace correspondant n'a été prévu au préalable pour lui.
Exemples :
Bannières publicitaires
Boîtes de recommandation
Flux de réseaux sociaux
Avis
Widgets externes
Contenus personnalisésSi de tels éléments déplacent du contenu vers le bas ou sur le côté, ils peuvent contribuer au CLS.
Comment le CLS est-il calculé ? #
Le CLS ne se base pas simplement sur le nombre de mouvements.
Pour un décalage de mise en page, il est pris en compte, entre autres, quelle part de la zone visible est touchée par des éléments instables et sur quelle distance ces éléments se déplacent.
Les différents déplacements de mise en page pertinents sont évalués au sein de fenêtres de session définies.
Pour l'optimisation pratique d'un site web, vous n'avez généralement pas besoin de calculer la formule vous-même. Il est plus important d'identifier les éléments responsables.
LCP, INP et CLS mesurent des problèmes différents #
Un site Web peut par exemple posséder les valeurs suivantes :
LCP : 1,9 s
→ bon
INP : 180 ms
→ bon
CLS : 0,32
→ mauvaisDans cet exemple, la page se charge rapidement et réagit bien aux interactions, mais présente d'importants décalages visuels.
Une affirmation générale telle que „ Le site web est rapide “ ne permettrait pas de cerner le véritable problème.
Un autre exemple #
LCP : 4,4 s
→ mauvais
INP : 120 ms
→ bon
CLS : 0,04
→ bonIci, le site web réagit bien et reste visuellement stable. Cependant, le contenu principal apparaît trop tard.
L'optimisation devrait par conséquent être axée en premier lieu sur le LCP ou sur sa cause.
différencier les données de terrain et les données de laboratoire #
Pour les Core Web Vitals, la distinction entre les données de terrain réelles et les données de laboratoire synthétiques est particulièrement importante.
Les données de terrain montrent les expériences réelles d'utilisateurs réels.
Les données de laboratoire sont générées dans des conditions de test contrôlées et conviennent particulièrement au diagnostic technique.
Nous expliquons les différences en détail sous Mesurer et évaluer correctement le temps de chargement d'un site web.
Pourquoi mes valeurs réelles et mes valeurs testées diffèrent-elles ? #
Les visiteurs réels utilisent différents appareils, connexions réseau et conditions de navigation.
Un test de laboratoire, en revanche, fonctionne avec des conditions définies ou simulées.
C'est pourquoi, par exemple, les résultats suivants peuvent survenir simultanément :
Test de laboratoire :
LCP anormal
Données de terrain réelles :
LCP bonou inversement.
Les deux résultats peuvent être corrects, car ils examinent des données différentes.
Où puis-je trouver des données réelles sur les Core Web Vitals ? #
Les données d'utilisation réelles peuvent notamment être affichées dans Google PageSpeed Insights, pour autant qu'il y ait suffisamment de données pour l'URL ou l'origine concernée.
Google Search Console propose également un rapport sur les Core Web Vitals.
Nous traitons de la configuration de la Search Console sous Configurer Google Search Console et valider le site web.
Pourquoi manque-t-il parfois des données sur les Core Web Vitals ? #
Une base de données suffisante doit être disponible pour les données de terrain.
Par conséquent, les sites Web nouveaux ou peu visités, ou encore certaines URL, peuvent éventuellement ne pas disposer de données de terrain suffisantes.
Ce n'est pas un problème de performance.
Important : Des données de terrain manquantes ne signifient pas que vos Core Web Vitals sont mauvais. Il se peut tout simplement qu'il n'y ait pas assez de données de mesure appropriées.
Données d'URL et données d'origine #
Les outils de performance peuvent afficher des données pour une seule URL ou des données agrégées pour une origine entière, selon la disponibilité.
Cela devrait être pris en compte lors de l'interprétation.
URL
→ page concrète
Origin
→ données agrégées
d'une même origine de site webUne bonne valeur d'origine ne garantit donc pas automatiquement que chaque page fonctionne de manière identique.
Core Web Vitals et appareils mobiles #
Les utilisateurs mobiles peuvent avoir des expériences de performance différentes de celles des utilisateurs d'ordinateurs de bureau.
Les différences naissent par exemple de :
Puissance de calcul
Connexion réseau
Taille de l'écran
Mise en page
Ressources chargées
Interactions des utilisateursC'est pourquoi vous ne devriez pas évaluer les problèmes de performance exclusivement sur un ordinateur de bureau puissant.
Core Web Vitals et SEO #
Les Core Web Vitals font partie des signaux techniques liés à l'expérience utilisateur d'une page.
Cependant, ils ne doivent pas être considérés comme un „ score de classement Google “ isolé.
Un bon LCP, INP et CLS ne garantit pas une position spécifique dans les résultats de recherche.
Inversement, tu ne devrais pas ignorer de mauvais indicateurs sous prétexte qu'une page est actuellement bien référencée.
Un site Web rapide, réactif et stable est avant tout utile pour vos visiteurs.
Passer de 90 à 100 n'est pas automatiquement l'optimisation la plus importante #
Les Core Web Vitals possèdent des plages de bonnes valeurs clairement définies. Cela ne signifie pas que tu dois ensuite éliminer chaque milliseconde supplémentaire à tout prix.
Si un site Web offre déjà une bonne expérience utilisateur, il peut être plus judicieux de résoudre des problèmes majeurs ailleurs.
Par exemple :
LCP 2,4 s → bien
mais :
Le tunnel d'achat ne fonctionne pas sur mobile
→ Le problème de tunnel d'achat a clairement une plus haute prioritéNe pas optimiser les Core Web Vitals de manière isolée #
Les mesures de performance technique peuvent avoir des effets secondaires.
Si vous retardez par exemple agressivement JavaScript uniquement pour améliorer une métrique, la navigation, les formulaires ou d'autres fonctionnalités peuvent être altérés.
Il en va de même pour une compression d'image excessive ou un chargement différé inadapté.
Règle de base : Une optimisation des performances n'est une amélioration que si le site web n'affiche pas seulement de meilleures métriques par la suite, mais continue également de fonctionner correctement et agréablement.
Optimiser systématiquement les Core Web Vitals #
Au lieu d'implémenter des mesures d'optimisation au hasard, tu devrais d'abord déterminer quelle métrique pose réellement problème.
Vérifier les Core Web Vitals
↓
Quel est le mauvais score ?
↓
LCP ?
INP ?
CLS ?
↓
Identifier la cause précise
↓
Modification ciblée
↓
Tester le site web
↓
Mesurer à nouveauSi le LCP est mauvais #
Commencez par les questions suivantes :
Quel est l'élément LCP ?
Quand est-il découvert ?
Quelle est la taille de la ressource ?
L'image est-elle correctement dimensionnée ?
Est-elle chargée en différé (lazy load) inutilement ?
D'autres ressources bloquent-elles l'affichage ?
À quelle vitesse le HTML est-il fourni ?Ensuite, tu pourras optimiser de manière beaucoup plus ciblée.
Si l'INP est mauvais #
Commencez par :
Quelle interaction est lente ?
Que se passe-t-il après le clic ou la pression d'une touche ?
Quelles tâches JavaScript sont en cours d'exécution ?
Le thread principal est-il bloqué pendant longtemps ?
Des scripts tiers sont-ils impliqués ?
De grands changements de DOM ou de mise en page sont-ils déclenchés ?L'objectif n'est pas simplement „ moins de JavaScript “, mais moins de travail inutile ou mal planifié lors d'interactions importantes.
Si le CLS est mauvais #
Examine :
Quel élément se déplace ?
Qu'est-ce qui déclenche le déplacement ?
Les dimensions de l'image sont-elles connues ?
Du contenu est-il inséré ultérieurement ?
Une police web modifie-t-elle la mise en page ?
Une bannière déplace-t-elle le contenu existant ?
Des widgets externes sont-ils impliqués ?Répare ensuite la cause concrète du décalage inattendu.
Plusieurs problèmes peuvent avoir la même cause #
Les problèmes de performance ne sont pas toujours clairement séparés les uns des autres.
Un widget JavaScript complexe peut, par exemple, recharger des ressources, solliciter le thread principal et insérer simultanément du contenu dans la mise en page.
Cela peut affecter plusieurs mesures.
Une analyse rigoureuse des causes est donc plus importante que l„“ optimisation isolée d'un chiffre ».
Mesurer à nouveau après les modifications #
Si tu as corrigé une cause précise, tu devrais tester à nouveau.
Les tests en laboratoire conviennent bien aux modifications techniques immédiates.
En revanche, les données de terrain réelles ne changent pas immédiatement, car elles sont collectées et évaluées sur une période prolongée.
N'attendez donc pas qu'une optimisation effectuée aujourd'hui modifie immédiatement l'ensemble des données de terrain.
Erreurs fréquentes liées aux Core Web Vitals #
Équivaloir le LCP à un temps de chargement complet
Équivaloir l'INP au TBT
Interpréter le CLS en secondes
Ne regarder que le score de performance
Ne tester que sur ordinateur
Interpréter l'absence de données de terrain comme de mauvaises valeurs
Activer systématiquement le chargement différé (lazy load) pour toutes les images
Désactiver JavaScript aveuglément
Considérer chaque changement de mise en page comme un problème de CLS
Assimiler de bons Core Web Vitals à de bons classements
Effectuer plusieurs optimisations en même temps
S'attendre immédiatement à de nouvelles données de terrain après des modificationsMatrice de diagnostic pratique #
| Problème | Premier examen |
|---|---|
| LCP mauvais | Identifier l'élément LCP et son chemin de chargement |
| INP mauvais | examiner les interactions lentes et le travail du thread principal |
| CLS mauvais | identifier les éléments et déclencheurs déplacés |
Liste de contrôle pour les Core Web Vitals #
Données de terrain disponibles ?
↓
Données d'URL ou d'origine ?
↓
Examiner le 75e centile
↓
LCP ≤ 2,5 s ?
↓
INP ≤ 200 ms ?
↓
CLS ≤ 0,1 ?
↓
Déterminer la métrique problématique
↓
Trouver l'élément / l'interaction en cause
↓
Analyser la cause technique
↓
Apporter la modification ciblée
↓
Tester le site web sur le plan fonctionnel
↓
Répéter le test en laboratoire
↓
Observer l'évolution des données de terrainRésumé #
Les Core Web Vitals examinent trois aspects différents de l'expérience utilisateur d'un site web.
LCP mesure l'expérience de chargement d'un contenu important et majeur et s'applique avec une valeur maximale de 2,5 secondes Alors bon.
INP évalue la réactivité aux interactions des utilisateurs. Une valeur d'au maximum 200 millisecondes est considéré comme bon.
CLS évalue les changements de disposition inattendus. Une valeur maximale de 0,1 est considéré comme bon.
Pour l'évaluation des données d'utilisation réelles, le 75e centile est déterminant. Cela permet de ne pas tenir compte uniquement des requêtes individuelles particulièrement rapides.
En cas de mauvais résultats, vous ne devez pas modifier immédiatement les paramètres généraux de performance. Identifiez d'abord l'élément concerné pour le LCP, l'interaction lente pour l'INP et le décalage de mise en page inattendu pour le CLS.
Les Core Web Vitals sont plus utiles lorsque vous ne les considérez pas comme trois chiffres à rendre le plus verts possible, mais comme des indications sur l'expérience concrète de vos visiteurs qui peut être améliorée.
