Optimiser les polices d’un site indépendant : polices système, font-display, préchargement et FOIT
1. Pourquoi les polices bloquent l’affichage du texte
Avant de recevoir le fichier de police, le navigateur ne sait pas à quoi le texte doit ressembler : son comportement par défaut est de rendre le texte invisible (FOIT, Flash of Invisible Text). Cette période de masquage était de 3 secondes sur les anciens navigateurs ; les nouveaux la ramènent à 1 seconde avant de forcer l’affichage avec une police de secours. Le problème : le texte principal du premier écran est justement l’élément LCP, et s’il attend la police, le LCP est tiré vers le bas par le temps de téléchargement de la police.
Erreur typique d’un site indépendant : pour faire “design”, l’auteur du thème charge toutes les graisses d’Inter ou de Roboto depuis Google Fonts (de 100 à 900, soit 9 graisses), à 100 Ko par graisse, soit 900 Ko en une seule fois. En 3G, rien que les polices prennent 3 à 5 secondes à télécharger et l’utilisateur voit un écran vide. Pour les indicateurs liés aux polices dans Core Web Vitals, voir Optimiser les Core Web Vitals, et pour la configuration du CDN, voir Accélération mondiale par CDN.
| Question | Impact sur les performances | Poids typique |
|---|---|---|
| Charger toutes les graisses (9 niveaux) | 800 Ko de téléchargement en plus au premier écran | 80 à 120 Ko par graisse |
| Police chinoise non sous-ensemblée | 2 à 8 Mo par fichier | Bien au-delà du budget du premier écran |
| font-display en block par défaut | FOIT : texte masqué 1 à 3 secondes | Texte invisible |
| Police critique non préchargée | Police découverte tardivement, 200 ms de retard | LCP ralenti |
| Utiliser plusieurs familles (plus de 3) | Chaque famille doit être téléchargée | 300 à 500 Ko cumulés |
2. La pile de polices système : la réponse par défaut pour un site B2B
La pile de polices système (system font stack) utilise les polices déjà installées sur l’appareil de l’utilisateur : aucune requête réseau, affichage immédiat. Le contenu d’un site indépendant B2B est surtout fait de tableaux de caractéristiques, de descriptions de cas et d’articles techniques ; la mise en page n’a pas besoin de police fantaisie ni de police de marque sur mesure. La pile de polices système suffit largement visuellement et reste cohérente d’une plateforme à l’autre.
Une pile CSS directement utilisable : font-family: -apple-system, BlinkMacSystemFont, “Segoe UI”, Roboto, “Helvetica Neue”, Arial, “PingFang SC”, “Microsoft YaHei”, sans-serif. Cette pile couvre macOS, Windows, Android et iOS, avec des polices système adaptées au français comme au chinois. Contre-intuitif :utiliser les polices système ne rend pas un site “peu professionnel”, au contraire : GitHub, Stripe ou Linear, qui font référence en design, utilisent tous des piles de polices système. Pour choisir un thème WP, voir la pile technique WordPress.
| Approche | Texte du premier écran | Téléchargement supplémentaire | Type de site concerné |
|---|---|---|---|
| Pile 100 % polices système | Affichage immédiat | 0 Ko | La plupart des sites B2B indépendants |
| 1 titre en police web | Remplacée après le fallback | 30 à 80 Ko | Sites qui misent sur l’image de marque |
| 2 familles de polices web | Remplacée après le fallback | 80 à 150 Ko | Sites de marque axés design |
| 3 polices web ou plus | FOUT/FOIT visibles | > 200 Ko | Déconseillé |
| Police web chinoise complète | FOIT de plusieurs secondes | 2 à 8 Mo | Quasiment impossible |
3. font-display: swap et FOIT : n’enfouissez pas votre texte
font-display est une propriété de @font-face qui contrôle l’affichage du texte pendant le chargement de la police. Quatre valeurs : auto (valeur par défaut du navigateur, autrefois block), block (masque brièvement le texte 3 secondes puis bascule sur le fallback), swap (affiche tout de suite le fallback, puis remplace une fois la police chargée) et optional (le navigateur décide seul, avec une tendance à ne pas télécharger la police).
Un site B2B indépendant devrait toujours utiliser swap. En 3G, block revient à laisser le premier écran vide pendant 3 secondes : le visiteur est déjà parti. optional convient à une police non essentielle à la marque, mais reste incontrôlable. On entend souvent que “swap provoque un flash de police (FOUT)”, mais pour un site B2B, il est bien plus important de laisser l’utilisateur lire les caractéristiques et les coordonnées que d’attendre une police décorative pour le titre. Un flash de police est parfaitement acceptable ; ce qui coûte cher, c’est un texte invisible. Pour la stratégie de chargement CSS/JS, voir l’optimisation CSS/JS.
| font-display | Période de blocage | Une fois la police chargée | Cas d’usage |
|---|---|---|---|
| auto/block | Texte invisible pendant 3 secondes | Remplacée par la police web | Déconseillé |
| swap | Affichage immédiat du fallback | Remplacée une fois la police prête | Valeur par défaut des sites B2B |
| fallback | Masqué 100 ms, puis fallback | Remplacée seulement si chargée en 3 secondes | Polices semi-critiques |
| optional | Masqué 100 ms, puis fallback | Pas de remplacement pour cette visite | Polices purement décoratives |
4. preload et sous-ensembles : accélérez ce qui doit l’être
Si le titre du premier écran doit absolument utiliser une police web, utilisez preload pour indiquer au navigateur de la télécharger en priorité : ajoutez dans le head <link rel=”preload” href=”font.woff2″ as=”font” type=”font/woff2″ crossorigin>. La police commence ainsi à se télécharger avant l’analyse du CSS, ce qui avance le LCP de 200 à 400 millisecondes. Attention : l’attribut crossorigin est indispensable, sinon le preload ne fonctionne pas.
Le subsetting est l’autre optimisation indispensable. Pour une police latine, on ne garde que les lettres, les chiffres et les symboles courants : on passe de 100 Ko à 30 Ko. Pour une police chinoise, le jeu de caractères est trop vaste : même après subsetting, elle pèse entre 200 Ko et 1 Mo, d’où notre recommandation d’utiliser directement les polices système sur un site chinois. Avec glyphhanger ou le paramètre text de Google Fonts, on ne charge que les caractères réellement utilisés. Un cas concret : le titre du premier écran n’utilise que 20 caractères chinois, on ne subsette que ces 20 caractères et le fichier passe de 4 Mo à 5 Ko. Pour le cache CDN, voir Comparatif des CDN.
| Action d’optimisation des polices | Gain de poids / de latence | Difficulté de mise en œuvre | Ce qu’on recommande |
|---|---|---|---|
| Format woff2 uniquement | 30 % plus léger que le ttf | Faible | Indispensable |
| Ne charger que les graisses 400 et 700 | 60 % de téléchargement en moins | Faible | Indispensable |
| Subsetter le jeu de caractères latin | 50 % de moins encore | Moyenne | Recommandé |
| Preload de la police du premier écran | LCP avancé de 200 à 400 ms | Faible | Titre du premier écran en |
| Police web chinoise complète | Négatif | Élevée | À ne pas faire |
5. Vérification : observer la cascade de chargement des polices dans DevTools
Comment vérifier que l’optimisation des polices est bien faite ? Ouvrez le panneau Network de Chrome DevTools, filtrez sur Font et regardez trois choses : le nombre de fichiers de police (2 familles maximum, 2 graisses maximum par famille), le poids des fichiers (50 Ko maximum par fichier pour être sain) et le moment où le téléchargement commence (avec un preload, la police doit figurer parmi les premières requêtes, pas être découverte après l’analyse du CSS). Tout fichier de police dépassant 100 Ko mérite qu’on vérifie si la graisse ou le subsetting n’est pas mal configuré.
Passez ensuite à Lighthouse et contrôlez les deux audits « Éviter les décalages de mise en page avec les polices web » et « Précharger les requêtes clés ». Une checklist applicable : font-display en swap partout, preload de la police du premier écran, format woff2, aucun ancien format ttf/eot, paramètre display=swap pour Google Fonts. Pour savoir comment gérer les polices d’un site multilingue, voir le traitement des graphiques sur un site multilingue. Pour la supervision du site, voir Alertes de supervision du site.
| Point de vérification | Critère de conformité | Outil de mesure |
|---|---|---|
| font-display | swap ou fallback partout | Inspection du CSS |
| Preload de la police du premier écran | Police du titre du premier écran préchargée | DevTools Network |
| Format des fichiers de police | woff2 uniquement | Filtre Font dans Network |
| Poids d’un fichier de police | ≤ 50 Ko | Colonne Size de Network |
| Nombre de familles de polices | ≤ 2 | Inspection du CSS |
| LCP au 75e percentile | ≤ 2,5 s | CrUX/RUM |
FAQ — Questions fréquentes
Un site B2B indépendant doit-il forcément utiliser une police web ?
Quelle différence entre font-display:swap et block ?
Peut-on utiliser une police web pour le chinois ?
Pourquoi ajouter crossorigin au preload d’une police ?
Comment charger Google Fonts le plus vite possible ?
Comment valider l’optimisation des polices ?
Six. FOUT et décalage de mise en page : comment éviter que ça bouge au changement de police
Avec la stratégie swap, quand la police de repli est remplacée par la police web, les largeurs et hauteurs de caractères diffèrent et la page peut sauter : c’est la source du CLS (cumulative layout shift). Stripe a mesuré qu’un remplacement de police provoque en moyenne 0,05 à 0,1 de CLS, soit exactement la limite du seuil acceptable de 0,1. Sur un site B2B, les textes sont longs et les paragraphes nombreux, et les différences de retour à la ligne font monter et descendre les images.
La solution passe par les descripteurs font-size-adjust et size-adjust. Dans @font-face, on utilise size-adjust: 105% et ascent-override pour aligner les métriques de la police web sur celles de la police de repli, et le remplacement ne bouge presque plus. Autre méthode plus simple : choisir un couple police de repli / police web aux métriques proches, par exemple Arial comme repli d’Inter, ou rester sur une pile de polices système sans changer de police. Un test concret : dans Lighthouse, regardez l’audit « éviter les décalages de mise en page sur les polices web » ; si le score est faible, vérifiez d’abord si c’est le swap qui en est la cause, puis décidez d’ajouter ou non size-adjust.
| Gérer le FOUT | Réduire le CLS | Difficulté de mise en œuvre |
|---|---|---|
| Ne rien faire, accepter le scintillement | 0,05 à 0,1 | Non |
| Ajuster finement les métriques avec size-adjust | Descendre sous 0,02 | Moyen, à tester |
| Choisir une police de secours aux métriques proches | Descendre sous 0,03 | Faible |
| Se passer carrément de police web | 0 | Coût zéro |
Pour conclure
Le jugement central sur l’optimisation des polices est simple : sur un site B2B, les visiteurs viennent lire des caractéristiques, consulter des cas clients et trouver un contact, pas admirer l’art typographique. Une pile de polices système est la bonne réponse dans 95 % des cas ; les quelques centaines de Ko et les quelques centaines de millisecondes économisées comptent bien plus que la différence visuelle. Même si vous gardez des polices web, tenez-vous strictement à ces quatre règles : deux familles, deux graisses, format woff2, chargement swap.
Trois étapes pour passer à l’action : d’abord, cette semaine, remplacez les polices du thème par une pile système et supprimez les appels Google Fonts superflus ; ensuite, ajoutez font-display:swap à toutes les polices web conservées, ne gardez que les graisses 400 et 700 et hébergez vous-même les fichiers woff2 ; enfin, ajoutez preload et crossorigin à la police du titre affiché en premier écran. Deux semaines plus tard, vérifiez si le LCP et les audits liés aux polices se sont améliorés.
Une phrase à retenir : personne ne reste une seconde de plus parce que votre site utilise Inter, mais tout le monde ferme l’onglet s’il attend 3 secondes que la police se charge. La police est un détail, mais ce détail décide si vous captez le visiteur pendant les 2,5 secondes du premier écran.