Core Web Vitals : LCP, INP et CLS, avec 25 correctifs

Core Web Vitals : LCP, INP et CLS expliqués

Core Web Vitals expliqués : LCP, INP, CLS et 25 correctifs avec code | We.Inc

Ce que mesurent LCP, INP et CLS, les seuils bons et mauvais, données terrain ou de laboratoire, un compteur en direct pour cette page, et 25 recettes de correction avec code classées par cause, plus des notes par plateforme.

Les Core Web Vitals sont trois mesures de visites réelles : Largest Contentful Paint (chargement, bon à 2.5 secondes ou moins), Interaction to Next Paint (réactivité, bon à 200 millisecondes ou moins) et Cumulative Layout Shift (stabilité, bon à 0.1 ou moins). Une page est validée quand au moins 75% des visites respectent les trois.

Bons scores

Le compteur ci-dessous mesure cette page dans votre propre navigateur pendant que vous l'utilisez. Trouvez ensuite la métrique qui échoue et suivez ses recettes ; chacune indique la cause qu'elle corrige et donne le code.

Questions fréquentes

Qu'est-ce qui a remplacé First Input Delay ?

Interaction to Next Paint a remplacé First Input Delay comme Core Web Vital en mars 2024. L'INP prend en compte toutes les interactions d'une page, pas seulement la première, et inclut le temps d'affichage du résultat.

Pourquoi mon score Lighthouse est-il bon alors que les Core Web Vitals échouent ?

Lighthouse, c'est un seul test sur un seul appareil simulé. Les Core Web Vitals reposent sur de vrais visiteurs pendant 28 jours, sur des téléphones et des réseaux plus lents, et incluent l'INP, que Lighthouse ne peut pas mesurer.

Les Core Web Vitals influencent-ils le classement Google ?

Ils font partie des signaux d'expérience de page de Google. Google décrit la pertinence et la qualité du contenu comme bien plus importantes, de bons vitals aident donc surtout quand les pages sont par ailleurs similaires.

Combien de temps avant que les correctifs apparaissent ?

Les données terrain couvrent les 28 jours précédents, les améliorations apparaissent donc progressivement sur environ quatre semaines après le déploiement.

En quoi c'est différent d'un score de vitesse

Les trois métriques

Seuils (évalués au 75e percentile des visites réelles)

Données terrain ou données de laboratoire

Données terrain ou données de laboratoire

Corriger le LCP (recettes 1 à 9)

1. Récupérer l'image hero en premier

fetchpriority="high" indique au navigateur que cette image compte le plus. Ne chargez jamais l'image LCP en différé.

2. Précharger une image LCP définie en CSS

Les images de fond sont découvertes tard, après le chargement du CSS. Un preload dans le head lance le téléchargement immédiatement.

3. Servir la bonne taille

srcset et sizes permettent à un téléphone de télécharger un petit fichier au lieu de celui prévu pour ordinateur.

4. Utiliser un format d'image moderne

L'AVIF et le WebP sont généralement bien plus légers que le JPEG à qualité égale. picture permet aux anciens navigateurs de se rabattre sur un autre format.

5. Ne pas masquer le texte pendant le chargement des polices

font-display: swap affiche immédiatement un texte de repli, un titre qui est l'élément LCP n'est donc pas retardé par le téléchargement d'une police.

6. Se connecter tôt au CDN d'images

preconnect effectue à l'avance la résolution DNS et les échanges TCP et TLS pour une origine tierce dont vous aurez besoin.

7. Différer les scripts inutiles à l'affichage de la page

Les scripts dans le head sans defer ni async bloquent le rendu. defer conserve l'ordre mais attend que le HTML soit analysé.

8. Envoyer du vrai HTML, pas une coquille vide

Si l'élément LCP est créé par JavaScript, rien ne peut s'afficher avant que le bundle soit téléchargé et exécuté. Le rendu serveur ou le prérendu le place dans la première réponse. Consultez notre guide SEO pour les single page apps pour connaître les options.

9. Mettre le HTML en cache à la périphérie

Une réponse serveur lente retarde tout. Mettez les pages statiques en cache sur un CDN et définissez un Cache-Control raisonnable.

Corriger l'INP (recettes 10 à 17)

10. Découper les tâches longues

Une tâche de plus de 50 ms bloque les saisies. Rendez la main au thread principal entre les morceaux pour qu'un clic puisse être traité entre-temps. scheduler.yield est plus récent ; la solution de repli avec setTimeout fonctionne partout.

11. Afficher le retour d'abord, travailler ensuite

Mettez à jour le bouton tout de suite, puis faites le travail lourd une fois que le navigateur a pu afficher.

12. Temporiser le travail lié à la saisie

Filtrer une longue liste à chaque frappe fait ramer la saisie. Attendez une courte pause.

13. Marquer les mises à jour React lentes comme transitions

startTransition permet à React de garder le champ réactif et d'afficher le résultat coûteux quand il le peut.

14. Retarder les scripts tiers

Les widgets de discussion et les gestionnaires de balises exécutent souvent du code lourd au chargement. Chargez-les une fois la page inactive ou à la première interaction.

15. Garder un DOM léger

Les pages énormes ralentissent chaque mise à jour de style et de mise en page. content-visibility saute le rendu des sections hors écran jusqu'à ce qu'elles soient proches.

16. Ne pas lire la mise en page dans une boucle d'écriture

Lire offsetHeight après chaque changement de style force un calcul de mise en page à chaque fois. Lisez tout d'abord, puis écrivez.

17. Déplacer les calculs lourds dans un Web Worker

L'analyse d'un gros fichier ou le tri de milliers de lignes peut s'exécuter dans un worker sans bloquer les clics.

Corriger le CLS (recettes 18 à 25)

18. Donner une taille aux images et vidéos

width et height permettent au navigateur de réserver l'espace avant l'arrivée du fichier. Le CSS peut toujours les rendre responsive.

19. Réserver l'espace des contenus intégrés

Cartes, vidéos et iframes se chargent souvent tard. aspect-ratio garde leur cadre ouvert.

20. Réserver l'espace des bannières et publicités

Un contenu inséré au-dessus de ce que les gens lisent le pousse vers le bas. Donnez à l'emplacement une hauteur minimale à l'avance.

21. Aligner la taille de la police de repli

Quand la police web prend le relais, le texte peut se recomposer. size-adjust sur une police de repli locale rapproche les deux en largeur.

22. Animer avec transform, pas avec top ou height

Déplacer des éléments avec transform ne déplace pas les autres éléments, cela ne compte donc pas comme un décalage de mise en page.

23. Superposer les bandeaux de cookies au lieu de pousser le contenu

Un bandeau fixé en bas de l'écran ne déplace pas la page ; un bandeau inséré en haut, si.

24. Utiliser des squelettes de la même taille que le contenu

Un espace réservé de chargement doit occuper la même place que ce qui le remplace.

25. Garder le back/forward cache fonctionnel

Les pages restaurées depuis le back/forward cache s'affichent instantanément sans nouveau décalage. Un gestionnaire unload l'empêche ; utilisez pagehide à la place.

Notes par plateforme

Notes par plateforme

Les images sont la cause habituelle d'un mauvais LCP ; allégez-les avec le

convertisseur WebP

Compteur en direct pour cette page

Mesure le LCP, le CLS et l'INP de cette page dans votre navigateur, là où c'est pris en charge.

Bon

À améliorer

Mauvais

Non pris en charge par ce navigateur

INP (le plus lent jusqu'ici)

En attente du plus grand affichage

Cliquez ou tapez n'importe où pour mesurer

Commencer gratuitement · Sans carte bancaire

Voir aussi: Guides

Produit

Pour qui

Fonctionnalités

Ressources

Entreprise

Plan du site