Calculer la performance d’un site web ne se résume pas à lancer un audit Lighthouse et lire un score sur 100. Depuis mars 2024, le remplacement de First Input Delay par Interaction to Next Paint (INP) a modifié la grille de lecture des Core Web Vitals, et avec elle, la méthodologie de mesure fiable.
INP, LCP, CLS : les métriques qui comptent réellement pour la performance web
Trois Core Web Vitals structurent aujourd’hui l’évaluation côté Google. Largest Contentful Paint (LCP) mesure le temps d’affichage du plus grand élément visible. Cumulative Layout Shift (CLS) quantifie l’instabilité visuelle de la page pendant le chargement.
A lire également : Un site Web a-t-il besoin d’une base de données ?
INP est le changement majeur. Contrairement à FID, qui ne captait que la latence de la première interaction, INP évalue chaque interaction tout au long de la session : clics, pressions tactiles, saisies clavier. Google a retiré FID de ses intégrations en septembre 2024. Tout audit qui mentionne encore FID comme référence est obsolète.
Le piège fréquent : se focaliser sur le score agrégé de PageSpeed Insights sans distinguer ces trois métriques. Un score global de 70 peut masquer un LCP correct mais un INP dégradé, ce qui affecte directement le ressenti utilisateur sur les pages interactives (formulaires, filtres, menus déroulants).
A lire aussi : Quels sont les langages de développement web ?
Données de laboratoire et données de terrain : pourquoi un seul test ne suffit pas
Un test synthétique (Lighthouse, GTmetrix en mode lab) simule un environnement contrôlé : connexion fixe, appareil standardisé, aucune extension navigateur. Les résultats sont reproductibles, mais ils ne reflètent pas ce que vivent les utilisateurs réels.
Les données de terrain proviennent du Chrome UX Report (CrUX). Elles agrègent les mesures collectées auprès d’utilisateurs Chrome sur une fenêtre glissante de 28 jours, présentées au 75e percentile. Deux conséquences directes :
- Une optimisation déployée aujourd’hui ne sera visible dans CrUX que plusieurs semaines plus tard, le temps que la fenêtre glissante se renouvelle
- Une dégradation temporaire (pic de trafic, script tiers défaillant) peut continuer à peser sur le score CrUX bien après sa correction
- Les données CrUX ne couvrent que les origines avec un volume suffisant de visites Chrome, ce qui exclut les sites à faible trafic ou ceux dont l’audience utilise majoritairement Safari ou Firefox
Nous recommandons de croiser systématiquement les deux types de données. Le lab identifie les causes techniques (JavaScript bloquant, images non compressées). Le terrain confirme si ces causes affectent réellement l’expérience sur le parc d’appareils de votre audience.
Performance mobile et desktop : deux calculs séparés
Analyser la performance sans séparer mobile et desktop revient à moyenner des réalités incomparables. Les contraintes de processeur, de bande passante et de rendu diffèrent radicalement. Un site peut obtenir un LCP satisfaisant sur desktop et échouer sur mobile à cause du poids d’une image hero non optimisée pour les petits écrans.
PageSpeed Insights affiche des résultats distincts pour chaque type d’appareil. Lighthouse, en revanche, simule par défaut un appareil mobile de milieu de gamme avec une connexion 4G throttled. Si vous testez uniquement en mode desktop dans DevTools, vous passez à côté des goulots d’étranglement mobiles.
Le réflexe à adopter : vérifier les données CrUX segmentées par appareil dans la Search Console (rapport « Signaux Web importants »). Un écart marqué entre mobile et desktop sur une même URL signale un problème d’adaptation responsive ou de chargement conditionnel mal configuré.
Outils de test de performance web : choisir selon l’objectif
Le choix de l’outil dépend de ce que vous cherchez à mesurer. Voici les cas d’usage concrets :
- PageSpeed Insights combine données lab (Lighthouse) et données terrain (CrUX) sur une même interface. C’est le point de départ pour un diagnostic rapide aligné sur les critères Google
- GTmetrix permet de choisir la localisation du serveur de test et le type de connexion simulée, utile pour les sites à audience géographiquement dispersée
- Chrome DevTools (onglet Performance) offre un profiling détaillé du thread principal, nécessaire pour tracer un INP dégradé jusqu’au script JavaScript responsable
- Le rapport CrUX brut (accessible via BigQuery ou l’API CrUX) fournit les données terrain sans l’interface simplifiée de PageSpeed Insights, avec la possibilité de requêter par origine, URL, type d’appareil et pays
Un audit complet articule au minimum PageSpeed Insights pour le diagnostic initial, DevTools pour le profiling technique, et CrUX pour la validation terrain.
Interpréter les résultats : au-delà du score global
Le score Lighthouse est une pondération de plusieurs audits. Un score de 90 ne garantit pas une bonne expérience utilisateur si le CLS est mauvais sur mobile. À l’inverse, un score de 60 avec des Core Web Vitals tous dans le vert en données terrain indique un site techniquement perfectible mais fonctionnellement satisfaisant pour les visiteurs.
La lecture pertinente consiste à isoler chaque métrique, vérifier sa valeur au 75e percentile dans CrUX, puis prioriser les corrections par impact. Un LCP lent affecte toutes les pages. Un INP dégradé cible les pages interactives. Un CLS élevé touche surtout les pages avec du contenu chargé dynamiquement (publicités, images sans dimensions explicites).
Chaque métrique pointe vers un type de correction différent : optimisation serveur et images pour le LCP, réduction du JavaScript sur le thread principal pour l’INP, déclaration explicite des dimensions d’éléments pour le CLS.
La performance d’un site web se calcule donc par couches : métriques individuelles, segmentation par appareil, croisement lab/terrain. Toute approche qui se limite à un score unique ou à un seul outil produit un diagnostic tronqué, inutilisable pour prioriser les optimisations techniques.
