« Le site est lent, il faut compresser les images. » La demande arrive presque toujours ainsi. Dans la plupart des cas que nous auditons, les images ne sont pas la cause dominante, et la personne qui pose la question a déjà lu dix articles qui commencent par ce conseil. La liste des actions possibles est partout. Ce qui manque, c'est la méthode: laquelle de ces actions déplacera quelque chose sur ce site précis, et dans quel ordre regarder.
Pourquoi un score Lighthouse élevé n'empêche pas un site lent
Le score de performance Lighthouse est une moyenne pondérée de cinq métriques de laboratoire: First Contentful Paint 10 %, Speed Index 10 %, Largest Contentful Paint 25 %, Total Blocking Time 30 %, Cumulative Layout Shift 25 %. Bandes fixes: 0 à 49 rouge, 50 à 89 orange, 90 à 100 vert. Seules ces métriques comptent: les sections Opportunities et Diagnostics, que tout le monde lit comme une liste de tâches, ne pèsent rien.
Ce score décrit une exécution simulée sur un appareil émulé, pas vos visiteurs, qui arrivent avec un cache froid, des extensions et souvent un appareil plus lent. La documentation liste elle-même les causes de variation d'une exécution à l'autre: tests A/B, routage internet, matériel, extensions. Le laboratoire sert à déboguer, le terrain sert à juger; comparer les deux et conclure au bug est une erreur de lecture.
Deuxième piège, l'INP ne figure pas dans ce score: c'est une métrique de terrain. En laboratoire, le proxy d'interactivité est le Total Blocking Time, qui pèse 30 %. Troisième piège, l'outil bouge: Lighthouse 13, publié le 10 octobre 2025 sur npm et arrivé dans Chrome stable avec Chrome 143 le 2 décembre 2025, a remplacé quinze audits par des audits « insight » et en a supprimé sept, dont first-meaningful-paint, sans changer le calcul du score.
Que mesure réellement chacune des trois Core Web Vitals
Elles sont trois: LCP pour le chargement, INP pour la réactivité, CLS pour la stabilité visuelle. L'évaluation se fait au 75e centile des chargements, mobile et ordinateur séparés. Ni moyenne ni médiane: la valeur retenue est celle en dessous de laquelle se situent 75 % des chargements, soit le seuil à partir duquel commence le quart d'utilisateurs le plus mal servi, d'où l'écart avec un site « rapide chez moi ».
LCP: à quel moment le contenu principal devient visible
Bon à 2,5 secondes ou moins, à améliorer entre 2,5 et 4,0 secondes, mauvais au-delà de 4,0. Le navigateur choisit l'élément parmi des candidats définis: balise img, image dans un svg, vidéo, élément portant une image de fond via url(), éléments de type bloc contenant des nœuds de texte. Première question du diagnostic: quel est l'élément LCP de cette page. Tant que vous l'ignorez, vous optimisez au hasard.
INP: le temps que met la page à répondre à une action
Bon à 200 millisecondes ou moins, à améliorer jusqu'à 500, mauvais au-delà. L'INP n'observe que trois interactions: clic souris, tap tactile, appui sur une touche. Le scroll, le survol et le zoom ne comptent pas. Sur les pages très interactives, la métrique écarte une interaction parmi les plus lentes par tranche de 50 observées. Une page sans clic, sans tap et sans frappe ne remonte aucune valeur: pas un bug, une absence de données.
CLS: ce qui bouge sous le doigt de l'utilisateur
Bon à 0,1 ou moins, à améliorer jusqu'à 0,25, mauvais au-delà. Le CLS n'additionne pas tous les décalages et n'en fait pas la moyenne: il retient la plus grosse rafale, la fenêtre de session, faite de décalages espacés de moins d'une seconde dans une fenêtre de cinq secondes maximum. Le score d'un décalage vaut la fraction d'impact multipliée par la fraction de distance.
Pourquoi TTFB, FCP et TBT ne sont pas des Core Web Vitals
Ces trois-là servent au diagnostic, pas au verdict. Le TTFB est bon à 0,8 seconde ou moins, mauvais au-delà de 1,8 seconde, et la documentation précise que, n'étant pas un Core Web Vital, il n'est pas indispensable d'atteindre le seuil « bon ». Le chiffre de 200 millisecondes qui circule partout vient d'une ancienne regle PageSpeed Insights de Google, « Improve Server Response Time », retiree avec l'API v4 en 2019: il ne figure dans aucune documentation Core Web Vitals actuelle, ou le repere est 0,8 seconde. Enfin, le FID n'existe plus: l'INP l'a remplacé le 12 mars 2024, jour de son retrait de la Search Console, et son support a pris fin le 9 septembre 2024 ailleurs.
Où prendre les données, et ce que chaque source ne voit pas
Ce que CrUX ne mesure pas
Le Chrome User Experience Report fournit les données de terrain: moyenne glissante sur 28 jours, mise à jour quotidienne. Pour y être inclus, un utilisateur doit avoir activé le rapport de statistiques d'usage, avoir activé la synchronisation de son historique de navigation, ne pas avoir défini de phrase secrète de synchronisation, et utiliser une plateforme supportée: Chrome desktop, Chrome Android, Custom Tabs, WebAPK. Donc rien de Safari ni de Firefox, rien du trafic iOS, et rien des autres navigateurs Chromium comme Edge. Donc rien de Safari ni de Firefox, et rien du trafic iOS.
Comment lire PageSpeed Insights sans se tromper
L'outil affiche deux blocs de nature différente. En bas, le laboratoire produit par Lighthouse. Si l'URL n'a pas assez d'échantillons distincts, l'outil bascule sur les données au niveau de l'origine: vous croyez lire une page, vous lisez un domaine. L'URL doit aussi être publique, crawlable et indexable pour avoir du terrain. Les tests de laboratoire, eux, partent de datacenters situés en Amérique du Nord, en Europe ou en Asie, le mobile émulant un appareil de milieu de gamme: d'où une partie de l'écart avec un visiteur réel à Dijon. Pour un premier relevé, notre outil d'audit de site donne un point de départ.
Pourquoi la Search Console ne bouge pas après un correctif
Le statut d'un groupe correspond au pire statut obtenu pour ce type d'appareil: une seule métrique mauvaise fait basculer tout le groupe. Rien n'y est en temps réel: un correctif déployé aujourd'hui ne s'y verra pas avant plusieurs semaines. Pour l'observer plus tôt, il faut une mesure maison chez les vrais utilisateurs, ou l'API CrUX History.
La méthode de diagnostic, dans l'ordre
1. Partir de la métrique qui échoue vraiment, sur le bon appareil
Le réflexe fréquent est d'appliquer une hiérarchie générique, souvent « l'INP d'abord ». Dans le même ordre, ordinateur puis mobile, le LCP est bon sur 74 % et 62 % de l'ensemble des sites, l'INP sur 97 % et 77 %, le CLS sur 72 % et 81 %. Le point de blocage le plus fréquent est le LCP mobile, pas l'INP. Ce repère calibre des attentes, il ne décide rien: le diagnostic part de vos données, appareil par appareil.
2. Décomposer le LCP en quatre segments
C'est l'étape que la plupart des articles sautent. Le LCP se décompose en quatre sous-parties, avec une répartition cible documentée: TTFB environ 40 %, délai de chargement de la ressource moins de 10 %, durée de chargement de la ressource environ 40 %, délai de rendu de l'élément moins de 10 %. Mesurez les quatre, comparez à cette répartition, le coupable apparaît sans discussion.
L'ordre de correction recommandé en découle:
- supprimer le délai de chargement, en rendant la ressource découvrable dans le HTML initial et en la priorisant;
- supprimer le délai de rendu, causé par du CSS bloquant, des scripts synchrones ou de longues tâches;
- réduire la durée de chargement, par le poids, le CDN et le cache;
- réduire le TTFB en dernier.
Cet ordre surprend, le serveur étant l'accusé habituel, mais un délai de découverte se supprime en quelques lignes de HTML quand un TTFB coûte un chantier d'infrastructure.
3. Décomposer l'INP en trois segments
Même logique: délai d'entrée, l'attente avant l'exécution des gestionnaires; durée de traitement, l'exécution des callbacks; délai de présentation, entre la fin des callbacks et la peinture de la frame suivante. Un délai d'entrée élevé signale un fil principal occupé au moment du clic, souvent par du script tiers. Une durée de traitement élevée pointe votre propre code, un délai de présentation élevé le rendu déclenché par l'interaction.
4. Isoler la phase qui domine le TTFB
Le TTFB n'est pas une valeur atomique mais une somme: redirections, démarrage du service worker le cas échéant, résolution DNS, connexion et négociation TLS, puis la requête jusqu'au premier octet. Tout le diagnostic consiste à isoler la phase dominante. Si le temps part dans les redirections ou dans TLS, un CDN change la donne; s'il part dans la génération de la réponse, il n'accélérera que les fichiers statiques et le problème restera entier.
5. Reproduire en local, avec le bon bridage
Le panneau Performance de Chrome DevTools affiche LCP, CLS et INP en local et en temps réel, à côté des données CrUX de la même page. Il propose un bridage réseau et processeur jusqu'à 20 fois dérivé de données réelles, met en surbrillance l'élément LCP et journalise les interactions avec leur latence. Tester sans bridage sur une machine de développeur ne prouve rien.
Les optimisations populaires qui ne changent rien
- Compresser des images qui ne sont pas l'élément LCP. Le poids baisse, le rapport s'améliore, la métrique ne bouge pas.
- Appliquer le lazy loading à toutes les images, celle du LCP comprise. On ajoute un délai de découverte sur la seule image qui compte.
- Attribuer toute variation à son propre code. Chrome a modifié l'INP pour ne plus inclure les événements pointerup utilisés pour le scroll sur mobile, ce qui a amélioré des scores et réduit la couverture de la métrique sur certains sites.
Où se cachent les problèmes sur un site e-commerce
Sur une boutique, les trois métriques ne se jouent pas au même endroit. Le LCP sur le grand visuel de la fiche produit et de la page d'accueil. Le CLS sur les bandeaux de consentement, les bandeaux promotionnels et les images sans dimensions déclarées. L'INP là où l'utilisateur agit: sélecteurs de variante, filtres de catégorie, ajout au panier, champs du tunnel. L'INP n'existant que s'il y a clic, tap ou frappe, une fiche consultée sans interaction ne remonte rien, alors que le tunnel de commande concentre tout.
Une amélioration de 0,1 seconde sur quatre métriques de vitesse s'y accompagne de 8,4 % de conversion et 9,2 % de panier moyen en plus dans le retail, 10,1 % de conversion en plus dans le voyage, 21,6 % de progression vers l'envoi de formulaire en génération de leads. Le fameux « 53 % des visites mobiles abandonnées au-delà de trois secondes » date, lui, de septembre 2016 et de 3 700 sites: à citer avec sa date, ou pas du tout.
Quand optimiser la vitesse n'est pas le bon choix
Supprimer la clause de motif et poser directement les cas: « Voici les situations où nous déconseillons le chantier. » Appliquer le meme traitement aux deux autres formulations. Premier cas, qui n'est même pas technique: quand les scripts occupant le fil principal sont imposés par un service marketing ou un gestionnaire de balises partagé, la seule action utile est de chiffrer le coût de chacun en millisecondes et de rendre l'arbitrage explicite.
Quand le terrain est déjà bon
Trois métriques dans le vert au 75e centile, sur mobile comme sur ordinateur: gagner encore 300 millisecondes ne changera ni le statut dans la Search Console ni le signal envoyé. Le seul argument valable pour continuer est un objectif de conversion mesuré sur vos propres données.
Quand le problème n'est pas la vitesse
Une page bloquée en vingtième position n'y est pas à cause de son LCP, mais parce qu'elle répond moins bien à l'intention que celles qui la précèdent. Google est explicite: il n'y a pas de signal unique, et de bons résultats dans le rapport Core Web Vitals ou dans un outil tiers ne garantissent pas un bon classement.
Quand une refonte est déjà décidée
Optimiser un thème, un empilement d'extensions ou un template qui disparaîtront dans quelques mois fait payer deux fois. Si la décision est prise, ou si l'audit montre que la structure produit elle-même le problème, rendu bloquant hérité, scripts tiers imbriqués, back-end qui régénère chaque page, la performance se traite dans le cadre de la refonte du site, quand les choix d'architecture sont encore ouverts. Corriger des symptômes sur une base condamnée est le cas où nous déconseillons franchement un chantier isolé.
Quand votre audience est majoritairement sur iPhone
CrUX ne remonte rien depuis iOS: vos rapports officiels décrivent alors une minorité de vos visiteurs, et la première dépense utile est une mesure, pas une optimisation. Depuis Safari 26.2, sorti le 12 décembre 2025, le LCP et l'Event Timing API qui permet l'INP sont supportés par les trois moteurs de navigateur, ce qui a fait passer ces deux métriques au statut Baseline Newly available. Le CLS, lui, reste non supporté hors Chromium, y compris dans la bibliothèque officielle web-vitals: proposé pour Interop 2026, il n'a pas été retenu dans la sélection annoncée en février 2026.
Quand on croit que le RGAA impose un temps de chargement
Le RGAA en vigueur, version 4.1.2, couvre 13 thématiques, des images aux formulaires: aucun critère ne porte sur le temps de chargement, la performance ou le poids des pages.
Ce que la vitesse fait, et ne fait pas, pour le référencement
Les Core Web Vitals sont utilisés par les systèmes de classement, et la même documentation précise qu'il n'y a pas de signal unique: l'expérience de page couvre aussi le HTTPS, l'adaptation au mobile et l'absence d'interstitiels intrusifs. Google ajoute que de bons résultats ne garantissent pas un bon classement, et n'a jamais quantifié le poids de ces signaux. Le Speed Update de juillet 2018, qui a fait de la vitesse un critère pour les recherches mobiles, s'accompagnait de deux précisions rarement citées: il n'affecte que les pages offrant l'expérience la plus lente et un faible pourcentage de requêtes, et l'intention de la requête reste un signal très fort, si bien qu'une page lente au contenu excellent peut rester bien classée. Le vocabulaire officiel parle de signal, jamais de pénalité.
Ce que cette méthode demande
Aucun outil payant, mais le refus de deux réflexes: commencer par les actions au lieu des mesures, et juger un site sur un score de laboratoire. La façon dont nous menons ce diagnostic est détaillée sur notre page dédiée à l'optimisation de la vitesse de chargement, et toute demande envoyée par écrit reçoit une réponse sous 24 heures ouvrées.