Performances et Core Web Vitals

La page Performances mesure les véritables Core Web Vitals (PageSpeed Insights), affiche les données CrUX des utilisateurs réels, les diagnostics Lighthouse par page et génère le ticket de développement.

La page Performances (barre latérale Analyse du site → Performances) mesure la vitesse réelle de votre site avec les Core Web Vitals de Google et transforme les diagnostics en indications concrètes pour le développeur. Elle s’appuie sur l’Audit SEO : chaque scan échantillonne quelques pages et mesure leurs performances ; pendant qu’un audit est en cours, la page affiche la progression en temps réel. L’onglet Core Web Vitals du rapport n’affiche que le tableau récapitulatif, avec un bouton pour ouvrir cette page.

Plan requis : inclus avec l’Audit SEO à partir du plan Solo. La génération du ticket de développement dispose d’un budget mensuel séparé (voir le tableau ci-dessous).

Comment les Core Web Vitals sont mesurés

Les données sont de véritables mesures Google PageSpeed Insights (Lighthouse mobile), pas des estimations : chaque audit échantillonne la page d’accueil + une page par type/chemin, jusqu’au plafond du plan, et mesure pour chacune le Performance score, le CLS, le LCP et le TBT.

Ce que mesure chaque colonne, et les seuils avec lesquels l’application les colore (vert = bon, jaune = à améliorer, rouge = faible) :

Les scores Lighthouse peuvent varier d’un audit à l’autre même si le site n’a pas changé (jusqu’à 20-30 %) : c’est la variabilité normale des tests en laboratoire, documentée par Google. Regardez la tendance sur plusieurs audits, pas le chiffre isolé.

Expérience réelle des utilisateurs (Chrome UX Report)

Si le site a suffisamment de trafic, une carte apparaît avec les données CrUX : LCP, INP et CLS au 75e centile, mesurés sur de vrais visiteurs Chrome au cours des 28 derniers jours, avec un verdict Bon / À améliorer / Faible. Contrairement aux scores Lighthouse, elles sont stables, et ce sont elles que Google utilise pour le classement. Le badge « site entier » signifie que la page individuelle n’a pas assez de trafic et que les données concernent tout le domaine.

Diagnostics Lighthouse par page

Sous les métriques, vous trouverez les diagnostics bruts de Lighthouse par page échantillonnée : une carte des décalages de mise en page (capture d’écran de la page échantillonnée avec les décalages les plus visibles, avec des cadres sur les éléments qui se déplacent pendant le chargement — une bordure en pointillés autour de toute la page indique un reflow global, par exemple dû aux polices web, avec les zones responsables surlignées en trait plein), le diagnostic LCP, les éléments à l’origine du CLS avec une colonne Cause (image sans dimensions, police web, iframe injecté — libellés en anglais, tels que fournis par Lighthouse), les polices non optimisées (FOUT), les images sans dimensions et les ressources bloquant le rendu.

Le tableau diagnostic LCP indique, pour chaque page échantillonnée, quel élément est le plus grand élément visible (celui qui détermine le LCP), ses phases de chargement — la phase dominante vous indique où agir : un TTFB élevé = serveur ou cache, Load Delay = élément découvert tardivement ou en lazy-loading, Render Delay = CSS ou polices bloquants — et le temps de réponse du serveur. Il n’apparaît que pour les audits lancés après l’activation de la fonctionnalité : si vous ne le voyez pas, lancez un nouvel audit.

Polices non optimisées (FOUT) liste les polices web provoquant un Flash of Unstyled Text : la page affiche d’abord le texte avec une police de secours puis la remplace à l’arrivée de la police web, avec un saut visible qui peut aussi compter comme un décalage de mise en page. Cela se corrige généralement en ajoutant font-display: swap et un preload pour la police, ou en la servant depuis le même domaine.

Un tableau vide n’est pas une erreur. La valeur du CLS et la liste des « éléments à l’origine du CLS » proviennent de deux mécanismes Lighthouse indépendants : un CLS élevé sans élément listé est normal, typiquement sur des pages avec des widgets/commentaires/embeds tiers que Lighthouse ne peut pas attribuer à un nœud précis. De même, des tableaux vides pour les images sans dimensions ou les ressources bloquant le rendu signifient simplement que Lighthouse n’en a détecté aucune sur cet échantillon.

Générer le ticket de développement

Générer le ticket de développement transforme les diagnostics en un ticket en langage clair pour chaque page échantillonnée, prêt à remettre à un développeur. Le ticket s’ouvre avec la cause racine déduite des phases de chargement et croise les données Lighthouse avec le HTML réel de la page : il nomme les fichiers et attributs exacts à modifier (par exemple un loading=lazy à retirer de l’image principale, ou un preload manquant) et adapte les conseils à la plateforme détectée, comme le thème ou les plugins WordPress installés. Il est généré à la demande mais une seule fois par audit (réactivé en relançant l’audit), avec un budget mensuel distinct de l’échantillonnage de pages — le compteur est visible sous le titre de la page Performances et dans Abonnement :

Vous voulez consulter le rapport technique complet ? Retour à Lancer votre premier audit SEO →

Dernière mise à jour: 5 septembre 2026