Quand faut-il précharger une police web critique ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre le problème

Précharger une police peut accélérer sa découverte lorsqu’elle est réellement critique et autrement trouvée tard, par exemple depuis une feuille de style. Mais une police préchargée occupe immédiatement des ressources réseau. Précharger plusieurs familles, poids et alphabets sans nécessité peut donc concurrencer le CSS, l’image LCP ou d’autres ressources plus importantes.

Inspecter le comportement réellement servi

Dans la waterfall, identifiez les fichiers de police utilisés au-dessus de la ligne de flottaison, leur initiateur et leur heure de découverte. Vérifiez le format, le poids typographique, le sous-ensemble de caractères et le nombre de fichiers chargés. Comparez la requête réellement consommée avec chaque link rel=preload présent dans le head.

Distinguer les mécanismes proches

Le preload anticipe une ressource précise ; font-display gère ce qui est affiché pendant son chargement. Les deux mécanismes peuvent coexister mais ne répondent pas au même problème. La préconnexion prépare une origine, alors que preload demande le fichier lui-même. Ne superposez pas ces hints sans vérifier la waterfall et la réutilisation de la connexion.

Identifier les causes probables

Les erreurs classiques sont un preload vers un poids qui n’est pas utilisé, un format différent de celui choisi par le CSS, un attribut crossorigin incohérent ou une URL qui diffère légèrement de la requête finale. Dans ces cas, le navigateur peut télécharger un fichier anticipé puis lancer une seconde requête pour la ressource réellement nécessaire.

Corriger à la bonne couche

Limitez le preload aux quelques fichiers indispensables au rendu initial et faites correspondre exactement URL, type et mode de requête avec @font-face. Utilisez des formats modernes supportés par votre cible et évitez de précharger toutes les variantes. Si la police n’est pas critique, laissez le navigateur la découvrir normalement plutôt que de lui réserver de la bande passante.

Traiter les cas limites sans automatisme

Une page peut utiliser des polices différentes selon la langue, le viewport ou la route. Un preload global dans le layout risque alors d’être inutile sur une grande partie du site. Les sous-ensembles latin et étendu peuvent également changer le fichier choisi. Vérifiez la page représentative avant de généraliser un hint au domaine entier.

Valider sur des cas réels

Après modification, contrôlez que le fichier préchargé est réutilisé par le texte, qu’aucun avertissement de preload inutilisé n’apparaît et qu’aucune requête n’est doublée. Comparez l’ordre de démarrage du CSS, de l’image LCP et des polices sur plusieurs runs à froid. Une amélioration locale ne doit pas dégrader la ressource réellement critique.

Conserver une preuve reproductible

Conservez les balises preload, la déclaration @font-face correspondante et la ligne réseau de la requête consommée. Notez URL, type, crossorigin, poids et page testée. Une preuve solide permet de relier le hint à un fichier réellement utilisé rapidement, au lieu de justifier le preload par la seule présence d’une police dans le site.

Prévenir la régression

Révisez les preloads à chaque changement de typographie, de sous-ensemble ou de poids. Ajoutez un inventaire des resource hints dans le contrôle de performance et supprimez ceux qui ne sont plus consommés. Pour un site à plusieurs gabarits, préférez une stratégie ciblée aux pages concernées plutôt qu’une liste globale qui grandit avec le temps.

Clôturer le diagnostic

Précharger une police est pertinent quand la mesure montre une découverte tardive d’un fichier critique et prévisible. Gardez le nombre de hints réduit, faites correspondre exactement la requête finale et mesurez leur concurrence avec les autres ressources. Le preload n’est pas une obligation pour toute police web.

Construire une matrice de contrôle

Pour preload des polices web, construisez une matrice qui sépare constat, intention, couche propriétaire et preuve finale. Le périmètre documentaire de cette page est volontairement borné : Limiter le preload aux polices réellement critiques et rappeler son coût potentiel sur les autres ressources prioritaires. Ajoutez au minimum le contexte de test, la valeur observée, le résultat attendu, l'origine technique supposée puis confirmée, et la méthode de revalidation. Quand plusieurs gabarits partagent le même composant, échantillonnez des cas représentatifs plutôt que de multiplier des constats identiques. Une anomalie ambiguë doit rester en revue jusqu'à ce qu'une preuve distingue clairement configuration, contenu et comportement réellement servi. Cette matrice permet aussi de vérifier qu'une correction locale ne masque pas un problème global et qu'un changement d'infrastructure n'est pas confondu avec une décision éditoriale.

Relier ce contrôle au reste du diagnostic

Ce sujet ne doit pas être traité isolément. Vérifiez les pages et contrôles liés /seo/performance-technique, /seo/polices-web-performance, /seo/font-display-performance, puis comparez leurs conclusions avec l'intention « preload polices web performance ». Les sources officielles associées à cette page sont webdev_fonts, webdev_preload; elles bornent les affirmations externes et doivent être revalidées si leur documentation évolue. Ne transformez pas une recommandation Limpi en règle universelle : distinguez ce qui est imposé par une spécification, ce qui dépend d'un moteur ou navigateur et ce qui relève d'un choix d'implémentation. Terminez par un contrôle de cohérence entre title, H1, contenu visible, canonical, maillage et données structurées. Si deux signaux se contredisent, conservez le cas en revue au lieu de conclure sur la base d'un seul outil. Consignez enfin la date du contrôle, le gabarit concerné et le propriétaire de la correction afin de pouvoir rejouer exactement le même scénario après une évolution du site. Pour différencier ce cas, relevez famille typographique, font-weight, font-style, unicode-range, fichier WOFF2, @font-face, crossorigin anonymous, type=font/woff2, sous-ensemble latin, glyphe, fallback system-ui, font-display, requête CORS, cache de police, preload inutilisé, poids 400, poids 700, variable font, axe wght, stylesheet initiator, priorité de police, réutilisation de requête et avertissement DevTools.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• webdev fonts
• webdev preload