Réduire le travail de police demandé à chaque route
Inventoriez les requêtes de polices en cache froid sur la page d’accueil, les pages de conversion, les vues connectées et les modèles avec différents systèmes de design. Notez la famille, la graisse, le style, le fichier, l’origine, la taille transférée et le sélecteur. Une règle déclarée @font-face ne déclenche pas à elle seule un téléchargement ; un navigateur récupère normalement une face quand la mise en page actuelle l’utilise. Cela rend les graisses et styles globaux inutilisés prioritaires à supprimer.
Utilisez une police personnalisée quand elle porte une réelle valeur de marque, souvent pour les titres d’affichage, et envisagez une pile système pour le corps de texte lorsque le design le permet. Ne supposez pas qu’une police variable est toujours plus petite : elle peut remplacer plusieurs fichiers statiques mais être plus volumineuse qu’une seule face statique. Comparez les actifs compressés réellement demandés par la route.
Supprimez les familles, graisses, italiques et polices d’icônes qui n’ont aucun usage au niveau de route testé.
Vérifiez que la licence autorise la distribution web, le subsetting et l’auto-hébergement avant de modifier le build.
Utiliser WOFF2 et sous-ensembleter sans enlever les caractères nécessaires
Commencez par WOFF2 comme base pour les navigateurs modernes. La recommandation du W3C décrit WOFF2 comme un paquet de polices web conçu pour une meilleure compression et une décompression rapide, et il est implémenté dans les principaux navigateurs. Conservez un autre format uniquement pour un besoin documenté de navigateur legacy ; sinon un fallback bien conçu est la voie de compatibilité la plus sûre.
Le subsetting crée un fichier plus petit contenant des glyphes sélectionnés, c’est-à-dire des formes de caractères. unicode-range peut associer des sous-ensembles à des plages de caractères afin que le navigateur choisisse un fichier pertinent lors du rendu du texte. Construisez les sous-ensembles à partir de pages réelles et des langues que vous supportez, y compris ponctuation, monnaies, noms, textes juridiques et scripts saisis par l’utilisateur. Les glyphes manquants sont un problème de correction, pas une économie d’octets acceptable.
Testez des pages localisées représentatives et les saisies de formulaires, pas seulement des exemples de design en anglais.
Assurez-vous que unicode-range et la plage poids/style de chaque sous-ensemble correspondent vraiment au fichier déployé.
Concevoir le fallback et la politique font-display ensemble
Une police fallback est ce que les utilisateurs voient quand la face personnalisée n’est pas prête. Choisissez-la pour des proportions similaires, puis comparez les vrais titres, boutons multiligne, navigation, tableaux, formulaires et longues chaînes localisées. Des largeurs différentes modifient les retours à la ligne ; un ascent, descent ou line-gap différent modifie la hauteur des blocs. Les deux peuvent déplacer du contenu déjà visible sur la page.
font-display définit le comportement de rendu pendant qu’une face est indisponible. optional a une période de blocage extrêmement courte et pas de période de swap, donc il peut convenir au texte de corps quand un fallback stable est préférable à la première visite. swap affiche rapidement le fallback et peut ensuite appliquer la police web, mais n’utilisez-le que là où un remplacement tardif n’entraînera pas un reflow disruptif. Block ou fallback doivent servir une raison de design testée, pas être un défaut global. La propriété CSS size-adjust peut aider à ajuster les métriques d’un fallback, mais vérifiez visuellement chaque script et chaque viewport supportés.
Ne faites pas dépendre le texte de paiement, de récupération, de compte, de sécurité ou de navigation d’une police personnalisée tardive.
Une lettre de fallback peut transmettre une mauvaise signification ; les icônes SVG sont généralement plus sûres pour les symboles d’interface.
Améliorer la découverte, mais restreindre preload et évaluer le flux de données
Une face déclarée uniquement dans une feuille de style externe peut être découverte après que cette feuille de style est téléchargée et parsée. Un CSS critique maintenable peut exposer une déclaration nécessaire plus tôt ; n’inlinez pas le binaire de la police, ce qui alourdit le document. Pour une origine tierce, preconnect peut établir la connexion plus tôt. Les requêtes de polices sont des ressources CORS, donc la livraison cross-origin et les preloads exigent un traitement crossorigin correct.
Preload est une priorité override, pas un interrupteur universel de vitesse. Il peut concurrencer d’autres travaux critiques et peut télécharger une face dont la route n’a jamais besoin ; il contourne aussi la sélection unicode-range. Corrigez d’abord la découverte tardive, puis preload au plus un fichier prouvé de première vue en utilisant l’URL exacte, as=font et crossorigin. Google Fonts indique que les requêtes API incluent l’adresse IP du visiteur, l’URL demandée, les en-têtes HTTP et le referer ; elle indique aussi que son API ne définit ni n’enregistre de cookies et n’utilise pas les informations collectées pour des profils ou de la publicité ciblée. L’auto-hébergement empêche Google de recevoir des données pour ces chargements. Évaluez la livraison, l’avis de confidentialité, la juridiction, les contrats et obtenez un avis qualifié si nécessaire.
Comparez des traces en cache froid et confirmez que le fichier préchargé est consommé sur la route.
Pesez l’établissement de la connexion, les capacités de cache et CDN, la maintenance des actifs et le flux de données visiteurs.
Versionnez les actifs de police et conservez une configuration CSS de fallback testée.
Tester le comportement rendu et traiter les polices comme une dépendance de résilience
Avec un cache froid, utilisez les outils réseau du navigateur pour inspecter la chaîne requête CSS→police, le timing, l’origine, le caching et les échecs. Répétez sur une connexion limitée, puis limitez ou bloquez la police. La réussite signifie un texte lisible, des contrôles utilisables, des symboles exacts et une mise en page cohérente avant l’apparition de la face personnalisée. Testez des mises en page réalistes mobile et desktop, de longues chaînes, erreurs, libellés de consentement, prix et chaque script supporté.
Dans Chromium, enregistrez un rechargement dans le panneau Performance et inspectez la piste Layout Shifts ; DevTools peut identifier les éléments déplacés et animer le déplacement. Le chargement de polices est un coupable connu, mais un élément déplacé n’est pas forcément la cause racine, donc corrélez la trace avec l’application de la police. L’API Layout Instability est spécifique à Chromium, ce qui rend les vérifications visuelles inter‑navigateurs importantes. Incluez les actifs de police, le comportement CORS, la politique de cache, les fallbacks et la possibilité de rollback dans la revue de sortie. Le mode dégradé attendu est du texte lisible, pas un contenu blanc ou une navigation cassée.
Un cache chaud peut masquer la requête initiale et le problème de rendu.
Reprenez la vérification quand les fichiers, le CMS, les templates, les fournisseurs ou les règles CDN changent.