Core Web Vitals : seuils LCP, INP, CLS et choix de refonte d’un site

Que mesurent le LCP, l’INP et le CLS ?

Les Core Web Vitals (signaux web essentiels) sont trois mesures de l’expérience réelle des visiteurs : le chargement, la réactivité et la stabilité visuelle.

LCP : le moment où le contenu principal apparaît

Le Largest Contentful Paint (LCP, affichage du plus grand élément de contenu) mesure le chargement.

INP : le temps que met la page à réagir

L’Interaction to Next Paint (INP, délai entre une interaction et l’affichage suivant) mesure la réactivité de la page.

CLS : les mouvements inattendus de la mise en page

Le Cumulative Layout Shift (CLS, cumul des décalages de mise en page) mesure la stabilité visuelle.

Pour repérer laquelle des trois pose problème, partez de la gêne observée sur votre propre site. Si vos visiteurs attendent devant un écran à moitié vide, regardez le LCP. Si un bouton « Envoyer » semble ne rien faire, regardez l’INP. Si quelqu’un appelle le mauvais numéro parce que la page a bougé, regardez le CLS. Lors d’une refonte, suivez-les séparément : un site peut réussir l’une et échouer sur une autre.

Quels sont les seuils d’une bonne expérience ?

Google fixe trois seuils sur web.dev : un LCP dans les 2,5 secondes après le début du chargement, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins. Une page n’est jugée conforme que si elle atteint les trois à la fois, au 75e centile des chargements.

Le 75e centile, en mots simples

Le seuil se mesure au 75e centile des chargements de page, ni sur la moyenne des visites ni sur la visite la plus rapide.

La règle de conformité

Une page qui réussit le LCP et l’INP mais dépasse 0,1 de CLS n’est pas conforme. Les trois seuils vont ensemble, et le calcul se fait séparément sur mobile et sur ordinateur.

L’erreur à éviter

Beaucoup de dirigeants jugent leur site en l’ouvrant depuis l’ordinateur du bureau, sur une connexion rapide, avec une page déjà en mémoire. Ce test ne dit presque rien : les Core Web Vitals décrivent l’expérience réelle de vos visiteurs, mobile compris. Appuyez-vous sur le rapport dédié de Search Console, qui montre les performances des pages, et testez vous-même sur un smartphone.

Pourquoi une page peut être bonne sur ordinateur et mauvaise sur mobile

Le seuil se mesure à part sur mobile et sur ordinateur : une même page peut donc être conforme dans une version et ne pas l’être dans l’autre. Le résultat qui compte pour décider est celui de la version qui échoue, mesure par mesure.

Une page d’accueil conforme sur ordinateur seulement

Sur ordinateur, la page d’accueil d’un cabinet comptable atteint les trois seuils : elle est conforme. Sur mobile, le LCP et l’INP passent aussi, mais le CLS dépasse 0,1. La page n’est pas conforme sur mobile. La correction porte sur la mise en page mobile, sans toucher au reste.

Une page contact lente à réagir sur mobile

La page contact d’un artisan respecte partout le LCP de 2,5 secondes et le CLS de 0,1. Sur mobile, l’INP dépasse 200 millisecondes : quand le visiteur tape dans le formulaire, les lettres apparaissent avec un temps de retard. L’image et la mise en page n’ont pas à être retouchées.

Connaître la part de vos visites sur mobile

La part des visites depuis un téléphone varie d’un site à l’autre : votre outil de statistiques, s’il en a un, permet de la connaître.

Règle de décision : listez, pour chaque page, la version (mobile ou ordinateur) et la mesure qui échouent, et traitez ces couples-là en premier. Une mesure déjà sous le seuil n’a pas besoin d’être optimisée davantage pour rendre la page conforme.

Où lire ses Core Web Vitals dans Search Console ?

Les résultats se lisent dans le rapport Core Web Vitals de Google Search Console, l’outil de Google pour les propriétaires de sites, qui montre les performances des pages. Google conseille de faire valider son site dans Search Console pour repérer les problèmes techniques.

1. Faites valider votre site dans Search Console. Votre prestataire ou votre hébergeur peut vous aider à placer l’élément de vérification, mais le compte doit rester au nom de l’entreprise.
2. Ouvrez le rapport Core Web Vitals. Lisez les résultats mobile et ordinateur séparément, puisque le seuil s’apprécie pour chacun. Commencez par le mobile si vos visiteurs viennent surtout de téléphones.
3. Repérez la mesure qui fait défaut et les pages concernées. Notez si le problème touche le LCP, l’INP ou le CLS, et s’il porte sur une page isolée ou sur un groupe de pages construites sur le même modèle (toutes les fiches de prestations, par exemple). Un défaut répété sur un modèle se corrige une fois, dans le modèle.
4. Utilisez l’outil d’inspection d’URL en cas de doute technique. Il montre le HTML que Googlebot, le robot d’exploration de Google, a reçu en explorant une page. Vous vérifiez ainsi que le titre et le texte principal figurent bien dans ce HTML, et pas seulement dans ce que votre navigateur affiche après exécution des scripts.
5. Notez l’état du site avant la refonte. Faites une capture datée du rapport, mobile et ordinateur, avec la liste des pages en défaut. Une fois le nouveau site lancé, vous comparerez sur la même base et pourrez demander des comptes précis à votre prestataire.

Search Console sert aussi à suivre d’autres indicateurs, dont l’apparition dans les fonctions d’IA de Google. Pour organiser ce suivi, consultez notre méthode pour mesurer sa visibilité dans les moteurs, de Google à Copilot.

Un conseil d’organisation : désignez une personne dans l’entreprise qui ouvre ce rapport à date fixe, par exemple chaque début de mois, et qui transmet au prestataire les pages qui changent d’état.

Quels choix de conception font gagner ou perdre le LCP ?

Le LCP se joue surtout dans le haut de la page d’accueil et des pages principales : ce qui s’y affiche en premier, et ce que le navigateur doit charger avant. Ces choix se décident à la maquette, bien avant le code.

L’en-tête : image, vidéo ou carrousel

Une grande photo en pleine largeur, une vidéo de fond ou un carrousel de cinq visuels deviennent souvent le plus grand élément affiché, donc celui dont dépend le LCP. Plus le fichier est lourd, plus il arrive tard. Avant de valider la maquette, demandez si l’en-tête peut tenir avec une seule image, préparée aux bonnes dimensions pour mobile et pour ordinateur, et si la vidéo apporte assez pour justifier son poids. Un carrousel ajoute en outre des scripts et des images supplémentaires dès l’ouverture.

Le message principal écrit en texte

Le slogan, le nom du métier et la zone desservie sont parfois intégrés dans une image par le graphiste. Écrits en texte, ils s’affichent plus tôt, restent lisibles par les lecteurs d’écran et par les moteurs. Pour ses aperçus IA et AI Mode, Google recommande d’ailleurs de proposer le contenu important sous forme de texte, accompagné d’images et de vidéos de qualité.

Polices et scripts chargés avant le contenu

Chaque police web supplémentaire (graisse, italique, seconde famille de caractères) et chaque script placé en tête de page peuvent retarder l’affichage. Limitez le nombre de familles et de graisses au strict nécessaire pour la maquette. Les scripts qui ne servent pas à afficher le haut de page peuvent être chargés après.

Gabarit ou code écrit pour la page

Un site monté sur un gabarit avec de nombreuses extensions peut charger du code dont la page n’a pas besoin : vérifiez-le avec votre prestataire. Pixel-iA a fait le choix d’écrire le code en HTML, CSS et JavaScript, sans gabarit de type WordPress, Wix ou Webflow. Quel que soit l’outil retenu, la question à poser au prestataire reste la même : qu’est-ce que la page charge avant d’afficher son contenu principal, et chaque élément est-il nécessaire ?

Si la maquette prévoit déjà un en-tête vidéo et trois polices, c’est le moment de trancher : après la mise en ligne, chaque retouche coûte une nouvelle série de tests.

Quels choix pèsent sur l’INP d’un site vitrine ?

L’INP se dégrade quand le navigateur est occupé au moment où le visiteur clique ou tape. Sur un site vitrine, les scripts ajoutés au fil des années et les éléments interactifs construits avec beaucoup de JavaScript font partie des causes à examiner.

Les scripts tiers sont les premiers suspects : fenêtre de discussion, carte interactive, vidéo intégrée depuis une plateforme, module d’avis, outils de mesure d’audience ou de publicité, boutons de partage. Chacun a été ajouté pour une bonne raison, souvent par des personnes différentes. Ensemble, ils occupent le navigateur pendant que le visiteur essaie d’ouvrir le menu ou de remplir le formulaire. Leur code appartient à un autre éditeur, ce qui limite les réglages possibles.

Les éléments interactifs viennent ensuite. Un menu à plusieurs niveaux animé, un filtre de réalisations, un simulateur ou un formulaire en plusieurs étapes peuvent être construits simplement ou avec une bibliothèque lourde. Pour un petit site vitrine, un menu qui s’ouvre sans animation élaborée rend le même service.

Certaines refontes reposent sur un framework JavaScript, c’est-à-dire un cadre de développement qui construit la page dans le navigateur. Google écrit qu’il peut traiter le contenu en JavaScript s’il n’est pas bloqué, mais que le SEO d’un tel site est en général plus complexe. Ce constat porte sur le référencement ; il justifie à lui seul de demander pourquoi ce choix est fait pour un site vitrine.

L’inventaire des scripts, en quatre temps

1. Demandez à votre prestataire la liste de tous les scripts chargés, page par page, y compris ceux des services tiers.
2. Notez en face de chacun sa fonction et la personne qui en a besoin dans l’entreprise.
3. Supprimez ceux qui ne servent à aucune décision ni à aucun visiteur : un outil de statistiques que personne ne consulte, un ancien pixel publicitaire, un widget abandonné.
4. Pour ceux qui restent, demandez s’ils peuvent ne se charger que sur la page qui les utilise, ou seulement quand le visiteur les active (une carte affichée après un clic, par exemple).

Quels éléments font décaler la page et dégradent le CLS ?

Un CLS au-delà de 0,1 vient souvent d’un élément qui prend sa place après que le texte s’est affiché. La correction consiste à réserver cet espace dès le départ, ou à afficher l’élément par-dessus la page sans pousser le contenu.

• Images et vidéos sans dimensions réservées. Si la mise en page ne connaît pas à l’avance la largeur et la hauteur d’une image, le texte s’affiche d’abord, puis descend quand l’image arrive. Exigez que chaque image et chaque vidéo ait ses dimensions déclarées dans le code.
• Bannière de cookies ou bandeau promotionnel inséré en haut. Un bandeau qui apparaît au-dessus de l’en-tête après l’affichage décale toute la page. Une bannière posée en surimpression, en bas ou au centre de l’écran, évite ce mouvement. Sa conception obéit aussi au droit : en Belgique, l’Autorité de protection des données (APD) estime qu’un bouton « accepter tous les cookies » sans bouton « refuser tous les cookies non strictement nécessaires » au même niveau compromet le caractère libre du consentement ; en France, la CNIL demande que l’on puisse accepter ou refuser avec le même degré de simplicité. Le détail figure dans notre article sur les règles de la bannière cookies.
• Polices web qui remplacent la police de secours. Le navigateur affiche parfois le texte dans une police système, puis bascule vers la police choisie, plus large ou plus étroite. Les lignes changent de longueur et les paragraphes se déplacent. Un réglage des polices de secours, aux proportions proches, limite cet effet.
• Encarts tiers chargés au milieu du texte. Une carte, un bloc d’avis, une publication de réseau social ou une vidéo intégrée qui arrive en retard repousse ce qui suit. Réservez-leur un emplacement de taille fixe.
• Contenus ajoutés par script après le chargement. Un message « nouveau » ou un compteur inséré au-dessus du texte produit le même décalage.

La vérification est à la portée de chacun : ouvrez chaque page principale sur un smartphone, de préférence en données mobiles, et commencez à lire dès que le texte apparaît. Si la ligne que vous lisiez se déplace, ou si un bouton glisse sous votre doigt, notez la page et l’élément en cause pour votre prestataire.

Ce que Google dit de la place des Core Web Vitals dans le classement

Google recommande vivement d’obtenir de bons Core Web Vitals et écrit qu’ils rejoignent ce que ses systèmes de classement cherchent à récompenser.

Cette formulation, publiée dans la documentation Google Search Central consultée le 30 septembre 2026, appelle une lecture prudente. De bons résultats améliorent l’expérience des visiteurs et vont dans le sens de ce que Google valorise ; ils ne remplacent pas un contenu utile, des pages qui répondent aux questions des clients, ni une fiche d’établissement à jour.

Et dans les fonctions d’IA de Google

Dans sa page consacrée aux aperçus IA et à AI Mode (consultée le 30 septembre 2026), Google cite parmi ses bonnes pratiques le fait d’autoriser l’exploration dans robots.txt et par le CDN ou l’hébergeur, de rendre le contenu accessible par des liens internes et d’offrir une bonne expérience de page. Son guide publié le 15 mai 2026 ajoute que les bonnes pratiques de SEO restent pertinentes pour ces fonctions d’IA générative, parce qu’elles reposent sur ses systèmes de classement et de qualité. Les autres conditions sont détaillées dans notre article pour apparaître dans les aperçus IA.

Ce que ces positions ne couvrent pas

Tout ce qui précède est la position de Google pour Google Search. Elle ne dit rien de la façon dont ChatGPT, Copilot ou Perplexity choisissent les sources qu’ils citent, et ne doit pas leur être transposée. Ces règles évoluent aussi : les dates indiquées sont celles des pages consultées.

Les promesses à écarter

Google invite à se méfier des outils tiers qui promettent un succès de classement ou prétendent utiliser des métriques « internes » de Google, et précise qu’aucun outil tiers n’a accès à ses systèmes internes de classement ou d’IA. Méfiez-vous donc d’un prestataire qui associe un score de performance à une position précise dans les résultats. Demandez-lui quelles mesures il améliorera, sur quelles pages, et comment vous le vérifierez dans Search Console.

Les questions à poser à votre prestataire avant et après la refonte

Pour que les Core Web Vitals comptent dans votre refonte, inscrivez-les dans le cahier des charges puis dans la recette, la vérification finale avant d’accepter le site. Les questions ci-dessous s’emploient avec n’importe quel prestataire.

Avant de signer

• Sur quels appareils réels la maquette et le site seront-ils testés, et le test inclut-il un smartphone d’entrée de gamme ?
• Quels scripts tiers seront chargés sur chaque page, et lesquels peuvent être évités ou chargés seulement à la demande ?
• Comment l’en-tête de la page d’accueil sera-t-il construit : une image, une vidéo, un carrousel, et à quelles dimensions pour mobile et pour ordinateur ?
• Les images, vidéos, cartes et bannières auront-elles un emplacement réservé pour éviter les décalages ?
• Le titre et le message principal seront-ils écrits en texte ?
• Le site repose-t-il sur un gabarit, des extensions ou un framework JavaScript, et pourquoi ce choix pour un site vitrine ?

Une fois le site lancé

• Qui consulte les résultats de chargement, de réactivité et de stabilité dans Search Console après le lancement, à quelle fréquence, et sous quelle forme vous transmet-il le résultat ?
• Le compte Search Console est-il au nom de votre entreprise, avec un accès pour le prestataire ?
• Quels ajustements sont compris après le lancement si une mesure dépasse son seuil sur l’un des deux types d’appareils, et pendant combien de temps ?
• Qui valide l’ajout d’un nouveau script ou d’un nouveau module, pour éviter que les performances se dégradent au fil des mois ?

À titre d’exemple de méthode, Pixel-iA prévoit dans sa phase de fabrication des tests sur de vrais appareils, puis, une fois le site lancé, une suite qui comprend des ajustements. Le déroulé complet est décrit sur la page création de site sur mesure.

Gardez les réponses par écrit et joignez-les au devis : elles servent de référence le jour de la recette, avec la capture du rapport prise avant la refonte.