Polices web : l'erreur de chargement qui pèse sur vos Core Web Vitals (et parfois sur le RGPD)

Une police d'écriture semble anodine : c'est du texte, pas une image en haute définition ni un script publicitaire. Et pourtant, la façon dont un site charge ses polices personnalisées influence directement deux des trois Core Web Vitals surveillés par Google — le LCP et le CLS — et, pour les sites qui utilisent Google Fonts sans y faire attention, elle peut aussi poser un problème de conformité RGPD. Voici ce qui se joue concrètement derrière ce chargement, et comment le régler sans renoncer à l'identité visuelle du site.

Ce que la police fait à votre LCP et à votre CLS

Un navigateur ne peut pas afficher de texte avec une police qu'il n'a pas encore téléchargée. Face à ce problème, il n'a que deux options par défaut, et aucune des deux n'est satisfaisante : soit il masque le texte jusqu'à ce que la police arrive — c'est le FOIT, le Flash of Invisible Text — soit il affiche d'abord une police de secours avant de la remplacer dès que la police personnalisée est prête — c'est le FOUT, le Flash of Unstyled Text.

Le FOIT dégrade directement le LCP quand l'élément le plus visible de l'écran initial est un titre en texte : tant que la police n'est pas arrivée, Google considère que rien d'important n'est encore affiché. Le FOUT, lui, dégrade plutôt le CLS : si la police de secours et la police personnalisée n'ont pas exactement les mêmes dimensions, le texte change de taille au moment du remplacement, et tout ce qui se trouve en dessous se décale — exactement le type de décalage inattendu que le Cumulative Layout Shift est censé mesurer.

Le point commun aux deux cas : le navigateur fait ce choix tout seul si le site ne lui donne pas d'instruction. Ce n'est pas une fatalité, mais une configuration par défaut qu'il faut reprendre en main.

La propriété qui tranche : font-display

La propriété CSS font-display, documentée par le W3C et reprise dans le guide officiel de Google sur le chargement des polices web, permet de dire explicitement au navigateur comment se comporter pendant que la police se télécharge (web.dev, Google). Elle accepte cinq valeurs, et le choix n'est pas neutre :

• block masque le texte pendant une courte période avant d'afficher la police de secours — c'est le FOIT, à éviter quand le texte concerné fait partie du contenu principal visible au chargement.
• swap affiche immédiatement la police de secours puis bascule vers la police personnalisée dès qu'elle est prête — c'est le FOUT, qui évite le texte invisible mais expose au décalage visuel si les deux polices n'ont pas les mêmes proportions.
• fallback est un compromis : une très courte période d'invisibilité, puis la police de secours, avec un délai limité au-delà duquel la police personnalisée n'est plus affichée du tout sur ce chargement.
• optional laisse le navigateur décider d'utiliser ou non la police personnalisée selon la vitesse de connexion constatée — la plus prudente pour les Core Web Vitals, mais la police perso peut ne jamais apparaître sur une connexion lente.
• auto laisse le navigateur choisir son propre comportement par défaut, ce qui revient à ne rien décider.

D'après les données collectées par corewebvitals.io sur un large échantillon de sites au deuxième trimestre 2026, swap est de loin le choix le plus répandu — environ un site sur deux l'utilise, suivi par auto puis par block (corewebvitals.io). swap reste un bon choix par défaut pour éviter le texte invisible, à condition de corriger le second problème qu'il peut poser : le décalage au moment du remplacement.

Corriger le décalage sans abandonner swap

Le décalage que peut provoquer swap ne vient pas de la bascule elle-même, mais de l'écart de proportions entre la police de secours et la police personnalisée. Deux leviers permettent de le réduire sans renoncer à swap :

1. Choisir une police de secours aux proportions proches. Une police système comme Arial ou une police de secours générique (sans-serif, serif) n'a pas forcément la même largeur moyenne de caractère que votre police de marque — plus l'écart est grand, plus le texte « saute » visuellement au moment du remplacement.
2. Ajuster les métriques de la police de secours avec size-adjust, ascent-override et descent-override. Ces descripteurs CSS, intégrés dans une règle @font-face dédiée à la police de secours, permettent de faire correspondre ses dimensions à celles de la police finale, pour que la bascule ne déplace quasiment rien à l'écran.

C'est une correction technique précise, mais elle ne demande ni refonte ni changement de police — uniquement un réglage dans le CSS existant, dans la même logique que le travail détaillé dans notre article sur les scripts tiers : un gain mesurable sans toucher au reste du site.

Précharger la police sans se tromper

Au-delà de font-display, le guide de Google recommande de précharger la police critique — celle utilisée par le texte visible dès l'arrivée sur la page — avec une balise <link rel="preload"> placée dans le <head>. Cela indique au navigateur de télécharger le fichier de police en priorité, avant même que le CSS ne soit entièrement analysé, au lieu d'attendre que la feuille de style révèle qu'une police externe est nécessaire.

Deux précisions évitent une erreur fréquente. D'abord, Google le dit explicitement : le préchargement rend la police plus susceptible d'être prête à temps, mais ne le garantit pas — ce n'est pas une solution magique, seulement une priorité donnée plus tôt dans la file de chargement. Ensuite, précharger toutes les polices du site, y compris celles utilisées plus bas dans la page, fait l'effet inverse de celui recherché : chaque préchargement entre en concurrence avec les ressources réellement critiques pour le premier affichage. Un ou deux fichiers de police maximum, ceux qui habillent le texte visible sans défilement, suffisent généralement.

Google Fonts et RGPD : le risque qu'on oublie

Beaucoup de sites chargent leurs polices directement depuis les serveurs de Google Fonts plutôt que de les héberger eux-mêmes. Cette méthode a un coût juridique rarement anticipé : par défaut, charger une police depuis le CDN de Google transmet l'adresse IP du visiteur aux serveurs de Google, sans que l'utilisateur en soit informé ni y ait consenti.

Le tribunal régional de Munich (LG München I) a tranché cette question le 20 janvier 2022 dans une affaire (3 O 17493/20) où il a accordé 100 € de dommages et intérêts à un visiteur sur le fondement de l'article 82 du RGPD, estimant que ce transfert d'adresse IP était injustifié dès lors qu'il était techniquement possible de servir la police sans passer par les serveurs de Google (The Hacker News). Le montant est symbolique, mais le raisonnement juridique, lui, ne l'est pas : il s'applique à tout site qui charge une ressource externe transmettant des données personnelles sans base légale adaptée.

La solution est simple et gratuite : héberger les fichiers de police directement sur votre propre serveur plutôt que de les appeler depuis Google Fonts. Cela règle le problème RGPD, et ça améliore souvent aussi la performance : c'est une connexion réseau externe en moins, avec sa résolution DNS et sa négociation de sécurité propres — le même type de coût caché que celui détaillé dans notre article sur les scripts tiers.

La check-list pour des polices qui ne pénalisent rien

• Limiter le nombre de polices et de graisses chargées : chaque variante supplémentaire (gras, italique, graisses intermédiaires) est un fichier de plus à télécharger.
• Définir font-display: swap sur les polices personnalisées, et ajuster les métriques de la police de secours pour limiter le décalage visuel au moment de la bascule.
• Précharger uniquement la ou les polices utilisées par le texte visible sans défilement, pas l'ensemble du catalogue de polices du site.
• Héberger les fichiers de police sur votre propre serveur plutôt que sur un CDN tiers, pour la performance comme pour la conformité RGPD.
• Servir les fichiers de police avec un cache de longue durée : une police change rarement, elle peut donc être mise en cache pendant des mois sans risque.

Un détail technique, un vrai impact business

Rien de tout cela ne demande de refondre un site ni de changer d'identité graphique. C'est le type de réglage qu'un site sur mesure permet de traiter précisément, fichier de police par fichier de police, plutôt que de dépendre d'un thème ou d'un plugin qui charge les polices à sa façon. Et le gain n'est pas que technique : un LCP plus rapide et un CLS plus stable jouent à la fois sur le classement Google et sur l'expérience réelle d'un visiteur qui attend de lire votre contenu, pas de regarder un texte sauter d'une taille à l'autre.

Si vous voulez savoir ce que le chargement de vos polices coûte réellement à votre site — Core Web Vitals et RGPD compris — contactez Origin : on fait l'audit avec vous, sans jargon ni engagement.