Bases de la performance de chargement des polices
La performance de chargement des polices se résume à trois leviers :
demander moins de fichiers de police, réduire la taille de chaque fichier, et
contrôler ce que le navigateur affiche pendant que les fichiers voyagent. En
pratique, cela signifie un ensemble discipliné de familles et de graisses,
WOFF2 comme seul format sur le fil, font-display: swap pour que le texte ne
soit jamais invisible, et un preload pour le ou les deux fichiers rendus en
premier.
L’ordre compte plus que la plupart des guides ne le laissent entendre. Les formats et les indices de preload relèvent du réglage ; le plus grand levier se situe en amont, dans le design : un système typographique qui a besoin de moins de polices. Un outil qui compose des systèmes typographiques n’a aucun outillage de performance à proposer ici — Scale Composer certainement pas — mais un système bâti à partir de deux familles et quatre graisses a tout simplement moins à charger qu’une page qui a accumulé des polices une décision à la fois, et aucun réglage ne comble cet écart. Cet article fait partie de notre guide de typographie.
Que se passe-t-il pendant le chargement d’une police web ?
Un texte mis en forme avec une police qui n’est pas encore arrivée place le navigateur dans une position délicate, et historiquement il a répondu de l’une de deux manières. FOIT — un éclair de texte invisible (flash of invisible text) — masque le texte jusqu’à ce que la police arrive ; la mise en page est stable mais le lecteur fixe un espace vide. FOUT — un éclair de texte non stylé (flash of unstyled text — en réalité : texte de repli) — affiche le texte immédiatement dans une police de repli, puis le remplace quand la police web arrive ; le lecteur peut lire aussitôt, mais le remplacement peut décaler la mise en page, car la police de repli et la police web occupent des espaces différents.
Les deux sont les symptômes du même écart entre le premier rendu et l’arrivée de la police. Toute la pratique du chargement des polices consiste à réduire cet écart ou à choisir, délibérément, ce qui le comble.
Que fait font-display: swap — et qu’est-ce que ça coûte ?
font-display: swap choisit volontairement le second comportement : afficher
le texte immédiatement dans la police de repli, puis le remplacer quand la
police web se charge. C’est la réponse standard parce que le texte invisible
est presque toujours le pire des échecs — un lecteur qui peut lire le texte de
repli n’a rien perdu, si ce n’est un peu de finition.
Le coût, c’est le remplacement lui-même. Si les lettres de la police de repli
sont plus larges ou plus étroites que celles de la police web, le remplacement
recompose la page — ce décalage que les utilisateurs perçoivent comme un texte
qui saute en pleine lecture. La solution moderne est l’ajustement métrique : la
propriété CSS size-adjust et ses descripteurs apparentés permettent de mettre
à l’échelle une police de repli pour que ses largeurs rendues approchent celles
de la police web, réduisant le remplacement jusqu’à le rendre quasi invisible.
Déclarer une police de repli ajustée sur les métriques est une pratique de plus
en plus standard, et de plus en plus générée par l’outillage plutôt qu’à la
main.
Pourquoi « moins de polices » est-elle la plus grande optimisation ?
Parce qu’avec les familles de polices statiques — contrairement aux polices variables, qui portent de nombreuses graisses dans un seul fichier — chaque famille × graisse × style que vous utilisez est un fichier distinct et une requête distincte. Le compte grimpe discrètement : une équipe ajoute une troisième famille pour une page marketing, une autre ajoute la graisse 300 pour une bannière d’accroche, et bientôt la page demande une douzaine de fichiers avant que le premier paragraphe ne se stabilise.
Un budget discipliné, en chiffres réels :
| Fichier | Rôle | WOFF2 sous-ensemble latin typique |
|---|---|---|
| Corps 400 | paragraphes, texte d’UI | ~15–40 Ko |
| Corps 600 | libellés, sous-titres | ~15–40 Ko |
| Titre 700 | titres | ~15–40 Ko |
| Titre 500 | affichage secondaire | ~15–40 Ko |
Quatre fichiers, atteignant couramment bien moins de 150 Ko au total — les tailles varient selon la couverture de glyphes, alors traitez ces fourchettes comme des ordres de grandeur plutôt que comme des chiffres exacts. La version indisciplinée — trois familles en quatre graisses chacune, plus quelques italiques — représente quatorze fichiers, souvent plusieurs centaines de kilo-octets, pour une page qui n’est pas plus belle.
La raison pour laquelle quatre graisses suffisent, c’est l’argument du système typographique : la hiérarchie vient d’une échelle typographique — des paliers de taille et des paliers de graisse qui travaillent ensemble — et non de l’ajout de polices. Une échelle plus deux familles plus quatre graisses au total couvre la plupart des produits.
Voir un système complet dans ce budget avec Scale Composer — chaque niveau, de la légende au titre d’affichage, tiré de deux familles et quatre graisses, aux tailles d’une véritable échelle. Voilà toute la facture de polices pour la page.
Quoi d’autre figure sur la liste de contrôle ?
Les éléments restants sont mécaniques. Le guide des bonnes pratiques pour les polices de web.dev traite chacun en profondeur ; les versions opérationnelles :
- WOFF2 uniquement. Tous les navigateurs actuels le prennent en charge, et il compresse nettement mieux que WOFF. Il n’y a aucune raison, en 2026, de livrer du TTF, de l’OTF ou de l’EOT à un navigateur.
- Préchargez le ou les deux fichiers critiques.
<link rel="preload" as="font" type="font/woff2" crossorigin>pour la police de corps (et peut-être la police de titre) lance ces téléchargements avant même l’analyse du CSS. Tout précharger annule l’intérêt — le preload est une revendication de priorité, et revendiquer la priorité pour six fichiers ne la donne à aucun. - Auto-hébergement ou hébergement Google : les deux conviennent. L’argument classique en faveur du CDN de Google — qu’une police mise en cache sur un site serait réutilisée sur le vôtre — a expiré lorsque les navigateurs ont cloisonné leurs caches HTTP par site. L’auto-hébergement vous apporte le contrôle des versions, des preloads en même origine et une dépendance tierce de moins ; l’hébergement Google vous apporte la commodité et le sous-ensemble automatique. Choisissez pour le contrôle ou la commodité, pas pour le mythe du cache.
- Créez des sous-ensembles si votre chaîne d’outils le permet. Un fichier
de police qui transporte des écritures que votre produit n’affiche jamais est
du poids mort. L’API CSS de Google sert déjà des sous-ensembles par écriture
via
unicode-range; si vous auto-hébergez, le sous-ensemblage devient votre affaire, et des outils existent pour ça.
Chargez moins en concevant plus serré
Déroulez la liste de contrôle dans l’ordre et le premier point fait l’essentiel du travail : moins de familles et de graisses est une décision de design au rendement plus élevé que n’importe quel réglage d’étape de build qui la suit. Le budget le plus serré de tous — hormis ne charger aucune police du tout — est une seule famille. Essayez la version à une seule famille du système — une hiérarchie complète à partir d’une seule famille et quatre graisses, une hiérarchie portée par la taille et la graisse seules : la plus petite facture de polices dans laquelle un système typographique complet puisse tenir.