Abderrahim ELBAHI
Un site peut afficher un CLS de 0 sur trois passages Lighthouse locaux et un CLS de 0,246 sur PageSpeed Insights, sans que rien n’ait changé entre les deux. La cause n’est ni le hasard ni le matériel : c’est le mode de throttling. En mode simulé, Lighthouse modélise les temps réseau au lieu de les appliquer, et un décalage provoqué par une police qui arrive en retard lui échappe par construction.
Le score local disait 99, PageSpeed disait 66
Le 18 août 2026, un rapport PageSpeed Insights sur la page d’accueil de ce site donnait une performance de 66 et un CLS de 0,246. Nos propres passages Lighthouse, joués la veille et le matin même sur les mêmes URL, donnaient 99 à 100 en performance et un CLS de 0.
La première conclusion a été la mauvaise : bruit du runner. Elle paraissait raisonnable — les scores PageSpeed varient d’un passage à l’autre, et le TBT de ce même rapport, à 510 ms, s’est effectivement révélé être du bruit puisqu’il est retombé à 60 ms au passage suivant.
Sauf que le CLS, lui, est revenu à 0,246 à la virgule près. Deux passages, même valeur. Un chiffre qui se reproduit n’est pas du bruit.
Pourquoi le mode simulé ne peut pas voir ce défaut
Lighthouse propose plusieurs manières de brider le réseau et le processeur. Le mode simulate, qui est celui par défaut de nombreuses configurations, exécute la page sans ralentir le réseau, puis applique un modèle mathématique aux temps mesurés pour estimer ce qu’ils auraient été sur une connexion lente. La documentation de Google sur le throttling de Lighthouse décrit les deux approches et leurs écarts.
La conséquence est directe. Si la police de caractères arrive avant que le texte ne soit peint, il n’y a jamais de bascule entre la police de repli et la police définitive. Aucun décalage n’a lieu. Le modèle, lui, allongera les temps après coup — mais il ne peut pas rejouer un décalage qui ne s’est pas produit.
Le mode devtools, lui, applique un vrai ralentissement au niveau du protocole. Rejoué avec un temps d’aller-retour de 150 ms, le même site rendait un CLS de 0,33.
npx lighthouse https://exemple.com --throttling-method=devtools --throttling.rttMs=150Trois mesures du même site, le même jour :
| Méthode | CLS mesuré |
|---|---|
Lighthouse simulate — local | 0 |
| PageSpeed Insights | 0,246 |
Lighthouse devtools, 150 ms | 0,33 |
Le décalage ne venait pas du titre, contrairement à ce que Lighthouse indiquait
Lighthouse désignait le h1 comme l’élément responsable. C’est exact et trompeur à la fois.
Le h1 de cette page porte une hauteur de ligne absolue, en pixels. Sa hauteur ne dépend donc pas de la police employée : que le texte s’affiche en police de repli ou en police définitive, la boîte du titre fait la même taille. Il ne peut pas grandir.
Ce qui bouge, ce sont les boîtes de ligne des éléments en ligne — le <em> à l’intérieur du titre, et les liens du chapeau qui se réenroulent quand la chasse des caractères change. Lighthouse impute le décalage au h1 parce que celui-ci s’est déplacé, pas parce qu’il a changé de taille.
La distinction n’est pas théorique : elle décide du remède. Corriger la hauteur du titre n’aurait rien donné.
Le remède : un repli calé sur les métriques, pas font-display: optional
Deux corrections sont possibles quand une police provoque un décalage.
font-display: optional demande au navigateur de renoncer à la police si elle n’arrive pas assez vite. Le décalage disparaît, mais les visiteurs les plus lents — ceux dont la connexion justifiait la mesure — ne voient jamais la police de marque. Le défaut est supprimé en supprimant la fonctionnalité.
L’autre voie consiste à caler la police de repli sur les métriques de la police définitive, pour que la bascule ne change ni la chasse ni la hauteur de ligne. Les propriétés size-adjust, ascent-override et descent-override existent pour cela, et MDN documente leur comportement.
@font-face {
font-family: TSr;
src: local(Arial);
size-adjust: 98%;
ascent-override: 102%;
descent-override: 31%;
}Les trois valeurs ne se devinent pas, elles se relèvent. Mesures faites au navigateur sur le même texte, corps 1000 px :
| Police | Chasse | Montante | Descendante |
|---|---|---|---|
| Police de marque | 12 417 | 1 000 | 300 |
| Arial | 12 674 | 905 | 212 |
system-ui | 12 159 | 967 | 211 |
La vérification porte sur les éléments qui bougent, pas sur le score
Un score peut s’améliorer pour une raison qui n’a rien à voir avec la correction. La seule vérification qui tienne consiste à mesurer les éléments dont on a établi qu’ils se déplacent.
Relevé à 1350 px de large, sur le <em> du titre et sur les liens du chapeau :
| Police affichée | <em> du titre | Liens du chapeau |
|---|---|---|
| Police de marque, réelle | 254 px | 28 px |
| Repli calé | 255 px | 28 px |
| Arial brut | 219 px | 24 px |
system-ui, ancien repli | 230 px | 26 px |
L’ancien repli se trompait de 24 px sur le <em>. Le repli calé tombe à 1 px. C’est cette mesure qui valide la correction — le score n’en est que la conséquence.
En local, la police arrive trop vite pour que la bascule ait seulement lieu : le test ne pouvait donc pas confirmer la correction non plus. Il a fallu déployer, puis relancer PageSpeed. Le CLS est passé à 0 sur ordinateur comme sur mobile, avec des performances de 99 et 100.
Pourquoi Arial et non system-ui
C’est le point qui rend la correction fiable ailleurs que sur la machine où elle a été écrite.
system-ui ne désigne pas une police : elle désigne celle du système. SF Pro sur macOS, Segoe UI sur Windows, Cantarell sur certaines distributions Linux. Des surcharges de métriques calées sur l’une seraient fausses sur les autres — le repli deviendrait la cause d’un décalage au lieu d’en être le remède.
Arial est présente sur macOS et sur Windows, et Liberation Sans lui est métriquement compatible sous Linux. Les trois valeurs relevées restent donc valables partout.
Ce que cette erreur apprend, et elle vaut au-delà du CLS
Le raisonnement initial était : trois passages locaux donnent 0, donc le 0,246 est une anomalie de mesure. Le raisonnement était faux, et il l’était pour une raison qui ne saute pas aux yeux — l’instrument employé pour réfuter le défaut était précisément celui qui ne pouvait pas le voir.
La règle tient en une phrase : un contrôle qui ne peut pas voir le défaut n’est pas une preuve d’absence.
La règle se généralise. Avant de conclure qu’un défaut signalé par un tiers n’existe pas, il faut établir que la méthode de vérification est capable de le détecter. Une vérification qui passe pour une mauvaise raison ressemble exactement à une vérification qui passe.
Comment le reproduire sur votre site
La démarche tient en trois étapes et ne demande aucun outil payant.
- Comparer les deux modes de throttling. Si
simulatedonne un CLS proche de zéro et quedevtoolsou PageSpeed en donnent un franchement supérieur, le décalage dépend du réseau — donc d’une ressource qui arrive en retard.
npx lighthouse https://exemple.com --throttling-method=simulate
npx lighthouse https://exemple.com --throttling-method=devtools --throttling.rttMs=150-
Identifier ce qui bouge réellement, et non ce que le rapport désigne. Les seuils de référence des Core Web Vitals sont publiés sur web.dev : un CLS supérieur à 0,25 est classé médiocre, en dessous de 0,1 il est bon.
-
Relever les métriques des deux polices plutôt que de reprendre des valeurs trouvées ailleurs. Elles dépendent du fichier exact que vous servez, pas du nom de la famille.
Ce que nous n’avons pas vérifié
Ce constat porte sur un site statique servant une police en woff2 avec font-display: swap. Nous n’avons pas mesuré si le même écart entre modes de throttling se produit avec d’autres causes de décalage — images sans dimensions, contenu injecté après le chargement, publicités. Le mécanisme laisse penser que oui pour tout ce qui dépend du réseau, mais nous ne l’avons pas éprouvé, et nous préférons le dire.
