Font display dans Lighthouse : ce qu'il signale et comment le corriger

L'avertissement font-display pénalise-t-il votre score ?

Lighthouse signale chaque police web chargée avec font-display: block, auto ou fallback via l'insight Font display (« Pensez à définir font-display sur swap ou optional »), appelé « Veillez à ce que le texte reste visible pendant le chargement des polices Web » avant Lighthouse 13. Il n'a aucun poids dans votre score, mais quand un titre constitue l'élément LCP, le masquer retarde le LCP sur mobile. Appliquez swap aux polices visibles en premier et alignez le fallback avec des metric overrides.

Que vérifie l'insight Font display ?

Dans Lighthouse 13 et PageSpeed Insights, l'insight indique : « Pensez à définir font-display sur swap ou optional pour vous assurer que le texte reste visible en permanence. swap peut être optimisé davantage pour limiter les décalages de mise en page grâce aux font metric overrides. » Avant Lighthouse 13, l'audit s'appelait « Veillez à ce que le texte reste visible pendant le chargement des polices Web ».

Lighthouse lit la trace d'enregistrement de Chrome lors du chargement de la page. Pour chaque police web que la page commence à télécharger, la trace enregistre la valeur font-display utilisée par Chrome. L'insight signale trois valeurs :

• block : le texte reste invisible jusqu'à 3 secondes pendant le téléchargement de la police.
• auto : aucune valeur définie. C'est ce que renvoie Google Fonts sans &display=, et ce que l'on retrouve sur les thèmes plus anciens, Font Awesome 4 et Material Icons.
• fallback : le texte n'est invisible que pendant 100 ms. Lighthouse 13 le signale tout de même.

Seules deux valeurs passent le test : swap et optional. Cela a changé avec Lighthouse 13. L'ancien audit validait block et fallback. Un site qui avait « corrigé » cela il y a des années avec fallback reçoit donc à nouveau l'avertissement. Les thèmes de blocs WordPress utilisent fallback par défaut, et Font Awesome 5 et 6 utilisent block.

« Est savings » correspond à la durée de la requête de police dans la trace, plafonnée à 3 000 ms. PageSpeed Insights enregistre cette trace sans throttling, ce qui donne souvent un chiffre faible. Le rapport ci-dessous est issu d'une page de test : la fiche produit d'une boutique d'équipement outdoor avec une police de titre condensée, mesurée sur mobile avec le throttling DevTools (Slow 4G). La police du corps de texte y a nécessité plus de 3 secondes, et le tableau affiche le plafond. Dans tous les cas, vous ne récupérerez pas ce temps : avec fallback, une police ne masque le texte que 100 ms au maximum, et avec auto, Chrome cesse de l'attendre 2 secondes après le début de la navigation.

À côté de la description, Lighthouse affiche deux libellés. FCP est la métrique sur laquelle Lighthouse estime que vous gagnez du temps. Unscored indique un coefficient de 0 : l'insight lui-même ne fait jamais varier votre score. Une police en block pénalise votre score via le Speed Index et le LCP.

Une règle @font-face non utilisée ne le déclenche jamais. Et parce que Lighthouse lit la trace, il liste désormais aussi les polices que vous n'avez pas ajoutées vous-même, comme un kit Typekit ou le fichier Google Fonts d'une extension. L'ancien audit affichait « unable to check » pour les polices provenant d'autres domaines.

Que se passe-t-il dans le navigateur pendant le chargement d'une police web ?

Le navigateur ne peut pas demander une police tant qu'il ne sait pas qu'un élément visible en a besoin. Il lui faut le HTML, puis le CSS, puis un calcul de style qui détermine que « ce titre utilise Barlow Condensed ». La requête de police ne démarre qu'à ce moment-là. Sur un mobile avec throttling, cela s'est produit à 0,74 s, une fois le HTML et le CSS reçus. Le navigateur découvre toujours les polices tardivement. Un preload ne fait qu'avancer ce démarrage : les polices bénéficient déjà de la priorité la plus élevée.

Dès cet instant, la valeur de font-display détermine ce que voit le visiteur. Voici les délais inscrits dans le code source des navigateurs :

Safari et Firefox masquent aussi le texte jusqu'à 3 s avec block et auto. Firefox attend 1,5 s de plus lorsque 75 % de la police est déjà reçue. Les deux masquent le texte pendant 100 ms avec fallback et optional, et Firefox fait de même avec swap.

Dans Chrome, block est plus lent qu'auto : auto applique le plafond de 2 secondes, pas block. Et optional dans Chrome ne prévoit aucune période de grâce de 100 ms. Sans preload, la police n'est pratiquement jamais prête pour le premier rendu, même avec un serveur rapide. Avec un preload, c'est possible si la police arrive dans les 100 ms environ du moment où la page est prête pour le rendu. Depuis le cache, sur la page suivante, elle l'est systématiquement.

La fiche produit au moment de son first paint, à 0,9 s sur un mobile bridé. Le bloc sombre correspond à la photo, encore en cours de chargement dans les deux cas. Page de test sur corewebvitals.io, Chrome 155, largeur de mobile 412 px, Slow 4G et ralentissement CPU 4x.

Avec block, le first paint affiche l'en-tête, le fil d'Ariane et la note par étoiles, mais laisse un espace vide à l'emplacement du nom du produit. La police du titre est légère (15 ko) et arrive à 1,7 s. La police du corps pèse 344 ko et continue de se télécharger quand Chrome cesse de l'attendre à 3,7 s ; jusque-là, il n'y a donc rien sous la photo. Avec swap, le nom du produit et la description sont lisibles dès le first paint.

La même page à 3 s : la police de titre et la photo sont arrivées, pas la police du corps.

font-display affecte-t-il le LCP, le CLS et le FCP ?

LCP

Un texte invisible ne peut pas être l'élément LCP. Avec block ou auto, un LCP textuel n'est comptabilisé que lorsque le texte devient visible : à l'arrivée de la police, ou à la fin de la période de blocage. Sur une page où l'élément LCP est un titre ou un paragraphe, block peut ajouter jusqu'à 3 secondes au LCP. Chrome en ajoute moins avec auto, et en Slow 4G, il a même affiché ce texte immédiatement en Arial. Avec swap, le LCP correspond au paint avec la police de fallback, et la bascule vers la police web n'ajoute pas de nouvelle entrée LCP, même si le texte avec la police web prend plus de place.

Sur la fiche produit ci-dessus, la photo est l'élément LCP sur toutes les versions ; font-display n'a donc pas fait varier le LCP dans ce cas. C'est la première chose à vérifier sur vos propres pages : l'élément LCP est-il du texte ou une image ? L'insight LCP breakdown dans ce même rapport Lighthouse l'indique.

CLS

Chaque swap qui modifie l'espace occupé par le texte déplace tous les éléments situés en dessous. Cela se produit aussi avec block et auto : le texte invisible réserve l'espace de la police de fallback, et le passage à la police web provoque le même saut. Les versions block, auto et swap ont toutes enregistré un CLS de 0,031 au moment où la police du titre est arrivée.

Avec un simple swap, le titre passe de trois lignes à deux quand Barlow Condensed arrive à 1,7 s. Tout ce qui se trouve en dessous remonte de 39 px : CLS 0,031. Le tracé en pointillés indique l'emplacement initial de la photo.

La même page avec une police de fallback qui ajuste l'échelle d'Arial Bold sur la largeur de Barlow (size-adjust: 68.32%). Le titre tient sur deux lignes dès le first paint et rien ne bouge : CLS 0.

swap valide donc l'insight Font display, mais conserve le layout shift. 0,031 reste inférieur à 0,1, mais sur une vraie fiche produit, une deuxième police qui arrive plus tard, un prix affiché dans une autre typographie ou une barre fixe peuvent se cumuler. Des metric overrides sur le fallback éliminent ce décalage.

Lighthouse ne vous orientera pas vers la police. Sur la version avec swap, Layout shift culprits incrimine la photo avec le motif « Unsized image element ». Elle dispose pourtant d'une largeur et d'une hauteur. Ce qui l'a déplacée, c'est l'arrivée de la police de titre à cet instant précis. Comparez le timing d'un décalage avec vos requêtes de polices avant de chercher des dimensions qui sont déjà bien présentes.

FCP

Lighthouse présente ces gains comme une économie de FCP. Sur la plupart des pages, c'est autre chose qui détermine le FCP : sur la fiche produit, l'en-tête et la barre de livraison utilisent une police système et s'affichent à 0,8 s, aussi bien avec block qu'avec swap. Lors de mon propre test, avec une page contenant uniquement du texte en police web, Chrome 155 a tout de même enregistré un FCP à 112 ms alors que le texte était invisible. Chrome considère le texte comme peint ; il saute seulement le tracé des glyphes. Le gain que Lighthouse affiche sur le FCP n'apparaîtra donc jamais dans votre FCP. Ce que vous perdez avec block, c'est le LCP d'un élément textuel, le Speed Index et ce que voit le visiteur.

Combien de sites reçoivent cet avertissement, et quand pouvez-vous l'ignorer ?

State of CWV analyse les règles @font-face sur la page d'accueil de 170 706 sites qui déclarent des polices web. La moitié de ces règles déclencherait l'insight si la police se chargeait : 39,7 % n'ont aucune valeur (auto), 9,6 % utilisent block et 0,9 % fallback. Seuls 471 sites utilisent la valeur optional quelque part.

Sites avec un bon LCP sur mobile, regroupés selon le nombre de fichiers de polices chargés par la page d'accueil et selon les valeurs de font-display dans leurs règles @font-face. State of CWV, octobre 2026 : 170 706 sites déclarant des polices web, CrUX p75 sur mobile, un bon LCP étant de 2,5 s ou moins.

Avec un ou deux fichiers de polices, la différence est minime : 88 % des sites n'utilisant que swap ou optional affichent un bon LCP sur mobile, contre 87 % des sites n'utilisant que block, auto ou fallback. Avec six à dix fichiers, l'écart passe à 6 points ; avec onze fichiers ou plus, il atteint 9 points. Les sites qui mélangent les deux s'en sortent le moins bien. Ils déclarent beaucoup plus de polices, avec une médiane de 44 règles @font-face contre 18, ce qui correspond typiquement à la police du thème, celle d'une extension et une police d'icônes. Le CLS ne présente quasiment aucune différence entre les groupes.

Il s'agit d'une corrélation. Les sites qui soignent leurs polices soignent généralement tout le reste. En ajoutant à cela le comportement des navigateurs vu plus haut, ma règle est simple : réduisez d'abord le nombre de fichiers de polices, puis configurez font-display.

Vous pouvez ignorer l'avertissement lorsque :

• la police ne s'applique qu'au texte situé sous la ligne de flottaison, comme le pied de page ou les avis ;
• votre élément LCP est une image et la police ne provoque aucun décalage.

Comment repérer les problèmes de polices dans vos field data ?

Lighthouse ne teste qu'un seul chargement sur un mobile simulé. Vos visiteurs utilisent toutes les connexions imaginables, et un visiteur qui revient a déjà la police en cache. Dans CoreDash, deux vues détaillées vous indiquent si les polices vous pénalisent.

• LCP by element. Si l'élément LCP sur mobile est un titre ou un paragraphe, une police configurée en block ou auto le retarde à chaque visite nécessitant le chargement de la police. S'il s'agit d'une image, la police ne touche pas à votre LCP.
• CLS by element. Un swap de police déplace ce qui se trouve sous le texte : la photo, la section suivante, le bouton d'achat. CoreDash nomme l'élément qui a bougé. L'outil ne vous dira pas qu'une police en est la cause : si l'élément déplacé est situé juste sous un titre ou un paragraphe et possède une largeur et une hauteur, un swap de police en est la cause probable.

CrUX fournit les mêmes métriques au p75 pour votre origine ou une URL, sur les 28 derniers jours, sans cette attribution.

LCP by element

CLS by element

CoreDash sur un exemple de boutique, acme-pagespeed.com, mobile, p75. Le titre du produit est l'élément LCP sur davantage de sessions que n'importe quel autre élément, avec un LCP de 3,28 s. Lorsque la photo du produit est l'élément LCP, le LCP tombe à 2,21 s. Dans le tableau CLS, cette photo, située juste sous le titre, occupe la première ligne : 0,07 sur 1 214 sessions. C'est toujours classé bon, mais aucun autre élément ne bouge sur autant de sessions.

Comment retrouver la police signalée dans les DevTools ?

Ouvrez la page dans Chrome, accédez au panneau Performance, réglez le réseau sur Slow 4G et le CPU sur un ralentissement 4x, puis enregistrez un rechargement. Le volet Insights liste Font display avec chaque police signalée. Cliquez dessus : les DevTools encadrent alors les requêtes de polices dans la piste Network.

Regardez ensuite où se termine chaque requête de police, où se situe le marqueur LCP, et si la piste Layout shifts présente un décalage juste après la fin d'une requête.

Pour retrouver chaque règle @font-face qui pointe vers un fichier signalé, ouvrez l'onglet Sources, lancez une recherche dans tous les fichiers (Ctrl+Maj+F, Cmd+Option+F sur Mac) avec le nom du fichier, puis définissez la valeur dans chaque règle trouvée.

Comment corriger l'insight Font display ?

L'URL de la police dans le tableau de Lighthouse vous indique sa provenance. C'est elle qui détermine où configurer font-display, ou si vous pouvez le faire.

Vos propres règles @font-face

Une police hébergée sur votre propre domaine sans /wp-content/, /cdn/fonts/ ou /_next/ dans son URL provient de votre propre CSS. Ajoutez font-display: swap à chaque règle @font-face correspondant à cette police, y compris les doublons dans une seconde feuille de style. Seule exception : les polices d'icônes, voir plus bas.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

Le tableau indique fonts.gstatic.com, mais le paramètre se place dans le lien fonts.googleapis.com/css2 qui charge la police. Ajoutez-y &display=swap :

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

Plus rapide encore : hébergez la police vous-même. Aucune connexion supplémentaire n'est requise, et vous maîtrisez le preload.

Adobe Fonts

Les polices chargées depuis use.typekit.net tirent leur font-display du projet web sur fonts.adobe.com : choisissez Modifier le projet et configurez-le dans la barre latérale. La valeur par défaut d'Adobe est auto, et ajouter un paramètre dans l'URL ne change rien.

WordPress

Les polices d'un thème contiennent /wp-content/themes/ dans leur URL. Dans un thème basé sur des blocs, définissez fontDisplay pour chaque police dans theme.json :

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

Dans un thème classique, ajoutez &display=swap à l'URL Google Fonts dans wp_enqueue_style, ou insérez font-display directement dans les règles @font-face du thème. Les polices sous /wp-content/plugins/ proviennent d'une extension ou d'un constructeur de page : cherchez d'abord un réglage de police à cet endroit. Concernant les polices Google Fonts chargées par un constructeur de page, le réglage d'Elementor se situe sous Elementor, Réglages, onglet Avancé : Google Fonts Load. OMGF permet d'héberger les polices Google Fonts localement et de forcer la valeur swap. Le guide WordPress détaille le reste des optimisations de polices et de CSS.

Shopify

Les polices des thèmes Shopify contiennent /cdn/fonts/ dans leur URL, sur le domaine de votre boutique. Elles sont injectées via le filtre font_face dans theme.liquid, et sans le paramètre font_display, aucun font-display n'est généré :

{{ settings.type_header_font | font_face: font_display: 'swap' }}

Dawn le configure déjà.

Next.js

next/font utilise display: 'swap' par défaut, précharge la police et génère un fallback avec des metric overrides (adjustFontFallback). Ses polices comportent /_next/static/media/ dans leur URL. Une police signalée présentant ce chemin s'est vu attribuer une autre valeur lors de l'appel à next/font (display: 'block') : modifiez-la directement à cet endroit. Une police signalée sans ce chemin a été chargée autrement : via une balise <link> vers Google Fonts dans le layout, ou un fichier CSS issu d'une bibliothèque de composants.

Polices impossibles ou déconseillées à modifier

• Une police d'icônes (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2) : avec swap, elle affiche des lettres ou des rectangles vides à la place des icônes. Remplacez dès que possible les polices d'icônes par des SVG, sinon laissez-les en block.
• Un plugin ou une application sans réglage de police (une extension WordPress, une police injectée par une application Shopify) : demandez au développeur d'activer swap.
• Un script tiers qui ajoute une police sur votre page (domaine du fournisseur) : vous n'avez pas la main. Chargez le script après le rendu de la page, ou ignorez simplement la ligne.

Charger moins de fichiers de polices

Supprimez les graisses et les styles inutilisés, et préférez une police variable unique à six fichiers statiques. Chaque fichier de police supprimé représente une requête de moins, un swap de moins et une ligne de moins dans cet insight.

swap ou optional : que choisir ?

Utilisez swap pour les polices associées à votre identité de marque, comme les titres et le logo, avec un fallback aligné. Réservez optional au corps de texte lorsqu'une police système convient également, et préchargez cette police pour lui donner une chance de s'afficher dès la première page :

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

L'attribut crossorigin est obligatoire, y compris pour une police hébergée sur votre propre domaine : sans lui, le navigateur télécharge la police deux fois. Dans Chrome, précharger une police peut retarder le premier rendu jusqu'à 100 ms ; limitez-vous donc au preload d'une ou deux polices, jamais de la totalité. En Slow 4G, les polices préchargées sont tout de même arrivées après le first paint, et la page a conservé le fallback.

Éliminer le layout shift grâce aux metric overrides

Donnez à la police de fallback les dimensions de la police web. Pour cela, créez une seconde règle @font-face qui pointe vers une police locale et ajuste son échelle :

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust correspond à la largeur de votre texte avec la police web divisée par sa largeur avec le fallback. ascent-override et descent-override correspondent aux valeurs d'ascent et de descent de la police web, divisées par ce même size-adjust. Des outils comme Fontaine et Capsize les calculent directement à partir des fichiers de polices.

Le principe est le même pour la police du corps de texte, mais vous devez mesurer sur votre propre contenu, à la largeur d'un mobile et à la taille que vous utilisez. Inter adapte sa largeur selon la taille de police : d'environ 98 % d'Arial pour des titres à environ 105 % à 18 px. Un size-adjust de 97,6 % faisait passer la description du produit sur cinq lignes avec le fallback contre six avec Inter, et le bouton d'achat bougeait encore. À 101 %, les deux s'alignent sur le même nombre de lignes. Pour vérifier, bloquez le fichier de police dans les DevTools (Network, clic droit, Block request URL), rechargez avec la largeur mobile et comparez les retours à la ligne avec un chargement normal. Ajustez size-adjust jusqu'à ce qu'ils correspondent.

local() ne trouve que les polices installées sur l'appareil : Arial est présente sur Windows, macOS et les iPhone ; les téléphones Android disposent de Roboto. Pour les visiteurs sur Android, ajoutez une seconde règle de fallback pour Roboto avec ses propres valeurs :

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

local() ignore une déclaration si la police n'est pas installée, de sorte que chaque appareil applique la première dont il dispose. Safari prend en charge size-adjust mais pas encore les overrides d'ascent et de descent ; la largeur correspond donc, mais avec line-height: normal, la hauteur de ligne peut varier légèrement. Ni WordPress ni Shopify ne proposent de réglage pour cela. Il faut passer par un développeur.

Comment vérifier que le correctif a fonctionné ?

Relancez Lighthouse sur mobile : Font display passe dans les insights validés. Sur la fiche produit, le score est passé de 97 à 98, uniquement grâce aux métriques pondérées : le Speed Index est passé de 1,9 s à 1,3 s parce que le texte s'affiche plus tôt, et le CLS est tombé de 0,031 à 0 grâce aux overrides. Vérifiez ensuite le CLS dans votre propre rapport : si la page bouge toujours à l'arrivée d'une police, le fallback a besoin de metric overrides.

Lighthouse 13.5.0, mobile, throttling DevTools.

Si vous avez choisi optional, la capture d'écran de Lighthouse montre généralement la police de fallback. Lighthouse charge la page à froid, et optional fait son travail.

CoreDash affiche l'impact par appareil dès la visite suivante. CrUX et Search Console couvrent les 28 derniers jours ; deux semaines après le déploiement du correctif, la moitié des données correspond donc toujours à l'ancien site.

Vous voulez savoir si une police maintient votre LCP ou votre CLS mobile dans le rouge ? Lors d'une power hour Core Web Vitals, nous analysons ensemble vos field data et une trace de votre page, et vous repartez en sachant exactement quelle règle de police modifier dans votre thème.