Ces trois métriques donnent un bon signal pour prioriser la performance technique de la landing page.
Pas un sujet de développeur : une variable de rentabilité double
Vous rangez peut-être les Core Web Vitals dans la case « technique, à voir avec les développeurs ». C’est une erreur de cadrage qui coûte de l’argent, parce que la vitesse est une variable double de votre rentabilité Google Ads.
Premier effet : la conversion. Une landing lente peut faire décrocher les visiteurs avant même qu’ils voient votre offre. C’est la première fuite du tunnel (la page dédiée) : vous avez payé le clic, la lenteur le fragilise avant l’arrivée.
Second effet : l’expérience de page de destination, l’une des trois composantes du diagnostic Quality Score avec le CTR attendu et la pertinence de l’annonce. Le niveau de qualité se calcule à partir de ces trois composantes : l’expérience de page n’est pas une métrique Core Web Vitals isolée, mais un signal à croiser quand la page est lente.
Une exécution lente peut donc vous coûter deux fois : moins de conversions, et une expérience de destination plus faible sur les requêtes concernées.
C’est exactement le double pont qui fait du CRO la seconde moitié de l’équation économique du SEA, le terrain que couvre tout mon travail sur la landing page et le CRO.
LCP, INP, CLS : que mesure chaque Core Web Vital ?
Les Core Web Vitals mesurent trois choses distinctes : identifiez laquelle pèche pour cibler la correction.
LCP (Largest Contentful Paint), le rendu du contenu principal. Le délai que met l’élément principal (hero, image, titre) à s’afficher. Repère Google : viser un LCP à 2,5 secondes ou moins au 75e percentile, puis descendre si le trafic mobile le justifie. Question posée : « Est-elle prête vite ? »
INP (Interaction to Next Paint), la réactivité. Le temps que met la page à répondre à chaque interaction (clic, tap, frappe). Seuil « bon » : sous 200 millisecondes.
INP a remplacé FID parce qu’il couvre l’ensemble des interactions, pas uniquement la première. C’est souvent la métrique la plus exigeante à corriger, car elle oblige à regarder le JavaScript, les formulaires et les scripts tiers. Crucial sur les formulaires : voyez comment réduire l’INP de vos formulaires pour le détail concret.
CLS (Cumulative Layout Shift), la stabilité visuelle. À quel point les éléments sautent pendant le chargement (un bouton qui se décale juste au moment du clic). Repère utile : une page doit rester visuellement stable pendant que l’utilisateur lit ou clique.
Causes typiques : images et vidéos sans dimensions déclarées, polices chargées en retard, contenu injecté dynamiquement.
- LCP
- Largest Contentful Paint : délai d’affichage du contenu principal.
- INP
- Interaction to Next Paint : délai de réponse à chaque interaction, qui remplace FID dans l’analyse des Core Web Vitals.
- CLS
- Cumulative Layout Shift : mesure des sauts visuels pendant le chargement.
- CrUX
- Chrome User Experience Report : base de données terrain utilisée par les outils de diagnostic.
Pourquoi « ça charge vite chez moi » ne suffit pas ?
Voici l’erreur qui invalide la plupart des auto-évaluations : tester son site sur sa propre machine (laptop puissant, fibre) et conclure « c’est rapide ». Les Core Web Vitals ne s’évaluent pas comme ça.
On les évalue sur le terrain, sur les vraies visites de vos vrais utilisateurs (via CrUX), au 75e percentile : pour « passer », au moins 75 % des visites doivent atteindre le seuil. Vos vrais utilisateurs sont souvent sur mobile, sur réseau moyen, avec des appareils moins puissants que votre machine de test.
La distinction d’outils compte : chacun mesure quelque chose de différent. Les données terrain disent ce que vivent les utilisateurs réels ; les tests labo expliquent pourquoi la page réagit comme ça. Pour prioriser une landing Google Ads, il faut les deux.
| Outil | Ce qu’il mesure | Rôle dans la décision | À quoi ça sert |
|---|---|---|---|
| PageSpeed Insights (onglet Terrain) | Données CrUX réelles, 75e percentile | Priorisation terrain | Savoir où vous en êtes |
| Google Search Console (Signaux Web essentiels) | Données CrUX agrégées par URL | Repérage des modèles de pages | Identifier les pages prioritaires à corriger |
| Lighthouse / PSI labo | Simulation sur machine contrôlée | Diagnostic technique | Comprendre pourquoi et diagnostiquer |
| CrUX API | Données terrain brutes par origine ou URL | Analyse fine | Analyse fine, comparaison dans le temps |
Regardez le terrain pour savoir où vous en êtes ; le labo pour comprendre pourquoi.
Limite honnête : les seuils et leur statut peuvent évoluer. L’effet chiffré varie selon les contextes : les études citent des corrélations entre passage des CWV et baisse du rebond ou hausse des ventes, ce sont des ordres de grandeur, pas des lois. Mais le principe est solide : la vitesse est une variable business, mesurée sur le terrain.
- Les Core Web Vitals sont une variable double : conversion (la lenteur fait décrocher) et expérience de destination.
- Trois métriques distinctes : LCP (chargement), INP (réactivité), CLS (stabilité visuelle).
- Mesure terrain d’abord : PageSpeed Insights / Search Console pour voir les visiteurs réels, Lighthouse pour comprendre les causes.
- Priorité : corriger le point bloquant d’abord sur données réelles, pas sur le score labo.
Le clic Google Ads lui-même dégrade-t-il vos Core Web Vitals ?
Oui, dans certains montages de suivi. Si le clic passe par une chaîne de redirections avant d’arriver sur votre page, le temps jusqu’au premier octet (TTFB) augmente, et le LCP peut suivre. Le problème ne vient pas du clic payant en lui-même, mais de la plomberie de tracking autour.
La conséquence est circulaire et coûteuse : vous payez une visite qui arrive plus lentement, donc une partie des utilisateurs décroche avant même de voir l’offre. Le diagnostic doit regarder les sessions issues des annonces, pas uniquement la performance moyenne du site.
Le mécanisme redirect → TTFB → LCP
Sans parallel tracking, le parcours d’un clic est : annonce → URL de suivi du clic (redirect) → éventuellement template de tracking tiers → landing page. Chaque redirect ajoute un aller-retour réseau. Sur mobile avec une connexion 4G correcte mais pas parfaite, cette chaîne peut représenter plusieurs centaines de millisecondes avant même que le navigateur charge le premier octet. Sur réseau moyen, la casse est encore plus marquée.
Avec le parallel tracking, le navigateur envoie l’utilisateur directement vers votre landing pendant que la requête de mesure s’exécute en arrière-plan. La chaîne de redirections pèse alors beaucoup moins sur le TTFB perçu par l’utilisateur.
Comment vérifier que le parallel tracking est bien activé
Le parallel tracking limite normalement cet effet en envoyant l’utilisateur vers la landing pendant que la mesure s’exécute en arrière-plan. Cela ne garantit pas que tout est propre dans votre compte, notamment si vous utilisez un template tiers ou un outil d’attribution qui ajoute ses propres redirections.
Pour vérifier : dans l’interface, allez dans Paramètres du compte → Paramètres de suivi et contrôlez que le suivi parallèle est actif quand l’option est exposée. Si vous utilisez un système de suivi tiers (redirections via un adserver, un outil d’attribution), vérifiez surtout sa compatibilité ; sinon, vos redirections peuvent subsister malgré l’activation côté Google Ads.
Seuil de vigilance : si votre TTFB terrain (visible dans PageSpeed Insights, onglet Données de terrain) est significativement plus élevé sur les sessions issues de clics payants que sur le reste du trafic, le parallel tracking ou un template tiers incompatible est probablement en cause. Un TTFB dégradé uniquement sur ces sessions-là est le signal à chercher.
Comment lire la note d’expérience de page de destination dans Google Ads ?
L’interface expose la composante « expérience de la page de destination » du Quality Score, mot-clé par mot-clé. La plupart des annonceurs ne l’activent pas et cherchent leurs CWV uniquement dans PageSpeed Insights ou la Search Console. Ces outils diagnostiquent la page ; la colonne Google Ads aide à repérer les mots-clés où l’expérience de destination est déjà signalée comme faible.
Activer la colonne dans l’interface
Dans votre compte, ouvrez le rapport Mots-clés (recherche). Cliquez sur l’icône Colonnes → Modifier les colonnes → Quality Score. Ajoutez ces quatre colonnes : Niv. de qualité, Expérience de la page de destination, Taux de clics attendu, Pertinence de l’annonce.
Cette colonne affiche l’une de ces trois mentions pour chaque mot-clé : Au-dessus de la moyenne, Dans la moyenne, En dessous de la moyenne. Elle ne dit pas « votre INP est mauvais », mais elle indique où l’expérience de destination mérite une lecture serrée.
Croiser avec CrUX pour prioriser
Une mention « En dessous de la moyenne » sur un mot-clé à fort volume est un signal prioritaire : la correction s’opère sur la landing associée, pas sur l’ensemble du site.
Workflow de diagnostic en 4 étapes :
- Lire cette colonne dans le rapport Mots-clés Google Ads, triée par volume. Identifiez les mots-clés « En dessous de la moyenne ».
- Ouvrir PageSpeed Insights sur l’URL visée par ces mots-clés (onglet Données de terrain). Vous voyez quelles métriques CrUX sont faibles.
- Repérer laquelle bloque : LCP lent → souci de chargement (cache, preload, scripts bloquants) ; INP faible → souci JavaScript (interactions, formulaires) ; CLS instable → souci de layout (dimensions d’images, contenu dynamique injecté).
- Prioriser la correction par enjeu business : commencez par les mots-clés à fort volume ou CPC élevé qui pointent vers les pages faibles.
Mobile vs desktop : faut-il séparer les diagnostics ?
Oui, il faut séparer les lectures. Une page peut être fluide sur desktop et pénible sur mobile : images trop lourdes, scripts qui bloquent le processeur, éléments qui sautent quand les colonnes s’empilent. Comme une grande partie du trafic payant arrive sur mobile, ignorer ce gabarit revient à optimiser la mauvaise expérience.
Pour vérifier si c’est votre cas : dans le rapport Mots-clés, segmentez les données par Appareil (icône Segment → Appareil). Comparez l’expérience de destination, le CPC et le taux de conversion entre Desktop et Mobile sur vos mots-clés principaux. Si le mobile décroche, la page mobile devient le chantier prioritaire.
La correction cible alors précisément le gabarit mobile : LCP (souvent les images hero non redimensionnées), INP (les scripts qui bloquent le main thread plus longtemps sur CPU mobile), CLS (les colonnes qui s’empilent différemment). Une landing page dédiée aide à isoler ces corrections sans toucher au gabarit desktop.
Les emplacements publicitaires dans la page dégradent-ils le CLS ?
Oui, dans un cas précis : si votre landing intègre des bannières display tierces (remarketing de réseau, monétisation, partenaires) dont les conteneurs ne réservent pas de hauteur fixe avant le chargement. Un slot publicitaire vide qui se remplit après le rendu initial pousse tout vers le bas au moment où l’utilisateur lit ou clique : c’est un layout shift mesurable.
Ce scénario concerne moins les landing pages pures (dédiées à une campagne, sans bannières) que les gabarits hybrides, articles, guides, catégories, qui reçoivent du trafic Ads ET affichent de la publicité display. Si vous y envoyez des clics, un CLS élevé peut venir de vos propres bannières tierces, au-delà de vos images ou polices.
Correctif simple : déclarez une hauteur minimale (min-height) sur chaque conteneur publicitaire avant que l’annonce se charge. Le navigateur réserve l’espace, le contenu ne se décale pas, et le CLS a beaucoup plus de chances de rester sous 0,1. Pas de refonte, pas de JavaScript supplémentaire.
Prioriser et corriger : les leviers concrets
Identifiez laquelle des trois pèche (LCP de chargement, INP de réactivité, CLS de stabilité) et corrigez le point bloquant d’abord.
Attaquez l’INP des formulaires avec comment réduire l’INP de vos formulaires, puis l’architecture : la mise en cache et l’architecture headless tirent le LCP vers le bas.
Traitez les scripts tiers qui plombent le rebond avant qu’ils mangent votre vitesse. Une exécution lente n’est pas un défaut esthétique : elle peut coûter en conversion et dégrader l’expérience perçue.
