Chargement responsive des polices web : une stratégie adaptée à l'appareil

Affichage responsive des polices et stratégie de préchargement responsive

En tant que spécialiste des Core Web Vitals, je vois chaque jour différentes solutions créatives. La plupart n'ont pas beaucoup de sens, mais de temps en temps, je tombe sur une stratégie si simple et si élégante qu'elle s'avère judicieuse pour certains sites.

Selon le Web Almanac 2025, 88 % des sites web utilisent des polices web (web fonts), chargeant une médiane de 4 fichiers de polices par page. Pourtant, seuls 12 % des sites préchargent (preload) les polices, et à peine 0,5 % utilisent font-display: optional. La plupart des sites traitent le chargement des polices comme un problème nécessitant une solution unique. Cet article explique une approche plus intelligente : charger les polices différemment pour les ordinateurs (desktop) et les mobiles.

La stratégie combine un préchargement responsive avec font-display: optional sur ordinateur (éliminant le Flash of Unstyled Text ou FOUT) et font-display: swap sur mobile (donnant la priorité à un rendu rapide du texte plutôt qu'à la cohérence visuelle).

Dernière révision par Arjen Karel en mars 2026

conseil : cette stratégie fonctionne bien pour les sites ayant un chemin critique de rendu (critical rendering path) plus important, c'est-à-dire les sites qui chargent plusieurs polices, feuilles de style et scripts avant l'élément LCP. Si votre site charge une seule police légère, la complexité ajoutée n'en vaut pas la peine.

Le problème du chargement précoce des polices

Lors de l'optimisation des Core Web Vitals, une règle simple s'applique toujours :
"Tout ce que vous faites avant le Largest Contentful Paint ralentira ce Largest Contentful Paint".

Ce principe s'applique également aux polices web. Donner la priorité au chargement des polices web pendant le chargement de la page peut améliorer l'expérience utilisateur, mais si votre site a du mal à atteindre les seuils des Core Web Vitals, en particulier pour certains types d'appareils, vous devrez peut-être trouver un équilibre entre l'UX et l'amélioration du LCP.

Le chapitre Performances du Web Almanac 2025 montre que le texte est l'élément LCP sur près de 24 % des pages mobiles. Lorsque le texte est l'élément LCP, la stratégie de chargement des polices affecte directement votre score LCP. Sur les 76 % de pages restantes où une image est l'élément LCP, les polices sont toujours en concurrence pour la bande passante réseau initiale et peuvent retarder le chargement de l'image.

Considérons l'exemple ci-dessous d'un site de journal néerlandais. Sur un appareil mobile, 3 polices sont mises en file d'attente avant l'élément LCP. Cela fait que les 3 polices sont en concurrence pour les ressources réseau initiales et retardent l'apparition de l'image.

Comprendre font-display: optional vs swap

Avant de plonger dans la stratégie responsive, vous devez comprendre les deux valeurs font-display sur lesquelles elle repose. Pour un aperçu plus large de font-display, consultez comment s'assurer que le texte reste visible pendant le chargement de la police web.

font-display: swap affiche immédiatement la police de secours (fallback font) et la remplace par la police personnalisée une fois qu'elle est chargée. C'est excellent pour le LCP car le texte est visible dès le départ. L'inconvénient : lorsque la police personnalisée arrive et remplace celle de secours, les différentes métriques de police peuvent provoquer un changement de mise en page (layout shift) visible, pénalisant votre score CLS. Environ 50 % des sites utilisent swap, ce qui en fait de loin la valeur la plus populaire.

font-display: optional donne au navigateur environ 100 ms pour charger la police. Si la police arrive à temps (généralement depuis le cache ou un préchargement rapide), elle est utilisée. Sinon, la police de secours est utilisée pour tout le chargement de la page et aucun remplacement ne se produit jamais. Cela signifie zéro changement de mise en page, mais la police personnalisée peut ne pas s'afficher lors de la première visite. Seulement 0,5 % des sites utilisent optional, bien que ce soit l'option la plus sûre pour le CLS.

Depuis Chrome 83, la combinaison de font-display: optional avec <link rel="preload"> bloque le premier rendu (first paint) jusqu'à ~100 ms (avec un maximum absolu de 1500 ms), en attendant que la police arrive. Si la police est préchargée, elle arrive presque toujours dans ce laps de temps. Le résultat : du texte stylisé dès le premier rendu, zéro FOUT, zéro changement de mise en page. C'est pourquoi le côté ordinateur (desktop) de la stratégie responsive fonctionne si bien.

La stratégie de police responsive à la rescousse !

Dans des cas comme celui-ci, où il y a une forte concurrence initiale sur le réseau, il est judicieux de faire la distinction entre les types d'appareils. Typiquement, les ordinateurs de bureau plus rapides sur des connexions filaires (et des connexions réseau plus rapides) peuvent gérer simultanément davantage de ressources réseau initiales, et il est tout à fait logique de précharger certains fichiers de polices critiques.

D'un autre côté, les appareils mobiles peuvent être utilisés sur le trajet du travail dans des conditions de réseau loin d'être optimales. Les appareils mobiles ont aussi souvent des processeurs plus lents et moins de mémoire disponible que les ordinateurs de bureau. Ces limitations signifient que traiter le chargement des polices différemment selon le type d'appareil peut s'avérer pertinent.

• Ordinateur (Desktop) : Le préchargement des polices améliore les performances de rendu sur les appareils disposant d'une meilleure bande passante et d'une plus grande puissance de traitement. Utilisez font-display: optional pour éliminer les problèmes de remplacement de polices. Combiné à un préchargement, Chrome bloquera brièvement le rendu (jusqu'à ~100 ms) pour attendre la police, vous offrant ainsi un texte stylisé dès le premier rendu avec un CLS de zéro.
• Mobile : Ne préchargez pas la police en raison de la concurrence sur le réseau. Utilisez font-display: swap pour un rendu plus rapide du texte. Cette approche affiche immédiatement les polices de secours tandis que la police personnalisée continue de se charger en arrière-plan, offrant une meilleure expérience sur les appareils moins puissants.

Implémentation à l'aide de <link rel="preload"> et des media queries

Au lieu de charger la police universellement, vous pouvez utiliser l'attribut media dans la balise <link> du HTML, avec du CSS, pour appliquer différentes stratégies de polices en fonction des types d'appareils.

Implémentation complète

<head>
  <!-- la balise meta viewport DOIT précéder les préchargements conditionnels aux médias -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Préchargement de la police pour ordinateur uniquement -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* Mobile : swap assure un rendu rapide du texte */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* Ordinateur : optional + préchargement = texte stylisé au premier rendu */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Quelques détails importants concernant cette implémentation :

1. Ordre de la balise meta viewport : La balise <meta name="viewport"> doit apparaître avant le lien de préchargement. Le scanner de préchargement du navigateur évalue l'attribut media avant d'analyser les autres balises meta. Si le viewport n'est pas défini, la requête média (media query) sera évaluée par rapport aux mauvaises dimensions sur les appareils mobiles.
2. Déclarations @font-face complètes : Chaque bloc @font-face doit inclure à la fois font-family et src. Contrairement aux propriétés CSS régulières, les descripteurs @font-face ne s'appliquent pas en cascade. Vous ne pouvez pas remplacer uniquement font-display dans un second bloc sans déclarer à nouveau la police entière. Le navigateur ignorera une règle @font-face incomplète.
3. L'attribut crossorigin : Les polices préchargées sans crossorigin seront récupérées deux fois. Incluez-le toujours sur les préchargements de polices, même pour les polices de même origine (same-origin).
4. Correspondance des points d'arrêt (breakpoints) : L'attribut media sur le préchargement (768px) doit correspondre à la media query CSS (768px). S'ils ne correspondent pas, vous préchargerez sur un point d'arrêt et appliquerez le mauvais font-display sur un autre.

Réduire les changements de mise en page sur mobile grâce à l'ajustement de la police de secours

La stratégie mobile utilise font-display: swap, ce qui signifie qu'il y aura un bref Flash of Unstyled Text lorsque la police personnalisée remplacera celle de secours. Vous pouvez minimiser ce saut visuel en utilisant les remplacements de métriques de polices CSS :

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

Les descripteurs ascent-override, descent-override et size-adjust vous permettent de faire correspondre les dimensions de la police de secours à celles de la police personnalisée. Lorsque le remplacement se produit, le texte bouge à peine. Ces descripteurs sont pris en charge par tous les navigateurs modernes. Des bibliothèques comme Capsize peuvent calculer automatiquement les bonnes valeurs de remplacement pour vos polices spécifiques.

Avantages de cette approche

• UX sur ordinateur : L'ordinateur affiche la page avec la police web dès le premier rendu, empêchant à la fois le FOUT et le FOIT (Flash of Invisible Text). Aucun changement de mise en page dû au chargement de la police.
• Performances sur mobile : font-display: swap garantit que les utilisateurs voient le texte immédiatement, même si la police personnalisée n'est pas encore chargée. L'absence de préchargement signifie que les polices ne concurrencent pas l'image LCP pour la bande passante.
• Simplicité déclarative : HTML et CSS purs. Pas de JavaScript, pas de bibliothèques de chargement de polices, pas de dépendances de framework. Cela signifie également que cela fonctionne avec n'importe quelle stratégie de priorisation des ressources que vous avez déjà en place.

Impact dans le monde réel

Cette stratégie est basée sur un exemple concret que j'ai rencontré lors de l'audit d'un site de commerce électronique. Le site chargeait 3 polices personnalisées : une police de titre, une police de corps de texte et une police d'icônes. Sur ordinateur, tout se chargeait assez rapidement pour que les polices causent rarement des problèmes. Mais sur mobile en 4G, les préchargements des trois polices étaient en concurrence avec l'image hero et poussaient le LCP bien au-delà du seuil de 2,5 secondes.

Après avoir mis en œuvre la stratégie responsive (préchargement uniquement sur ordinateur, suppression des préchargements de polices sur mobile) :

• Ordinateur : Amélioration du CLS et de l'UX avec des polices stylisées apparaissant dès le premier rendu. La combinaison préchargement + font-display: optional a éliminé tous les changements de mise en page liés aux polices.
• Mobile : First Contentful Paint et Largest Contentful Paint plus rapides, car les polices n'étaient plus en concurrence pour la bande passante initiale. L'image hero s'est chargée sans contention.

Une recherche de DebugBear confirme cet impact : le préchargement des polices peut améliorer le LCP d'environ 30 % (passant de 1,82 s à 1,24 s) lorsqu'il est appliqué correctement. Mais lorsqu'il est surexploité (un site avait 38 polices préchargées !), le préchargement aggrave les choses. L'approche responsive vous offre les avantages du préchargement sur ordinateur sans en payer le coût sur mobile.

Sur les sites surveillés par CoreDash, environ 82 % des chargements de pages sur mobile réussissent le LCP lorsque les polices sont préchargées de manière stratégique, contre 70 % pour les pages qui chargent toutes les polices de la même manière, quel que soit le type d'appareil. Sur ordinateur, où la combinaison préchargement + optional fonctionne le mieux, l'écart est encore plus grand.

Quand utiliser cette stratégie (et quand l'éviter)

Utilisez cette stratégie lorsque :

• Votre site charge 2 fichiers de polices personnalisées ou plus.
• Le mobile et l'ordinateur ont des profils de performance Core Web Vitals différents (courant sur les sites où le mobile peine avec le LCP tandis que l'ordinateur réussit).
• Les polices sont en concurrence avec d'autres ressources critiques (images hero, CSS critique) sur mobile.
• Vous auto-hébergez vos polices (cette stratégie fonctionne avec n'importe quel hébergement de polices, mais l'auto-hébergement vous donne un contrôle total sur le chemin de préchargement).

Évitez cette stratégie lorsque :

• Vous ne chargez qu'une seule police WOFF2 légère (moins de 20 Ko). La complexité (overhead) du chargement responsive n'en vaut pas la peine.
• Votre site réussit déjà tous les Core Web Vitals à la fois sur mobile et sur ordinateur. N'ajoutez pas de complexité à un problème que vous n'avez pas.
• Vous vous appuyez sur les polices système. Si vous utilisez déjà font-family: system-ui, sans-serif, il n'y a rien à optimiser.

Après avoir mis en œuvre cette stratégie de chargement de polices, ou toute autre, surveillez son impact avec le Real User Monitoring pour confirmer que le changement a réellement amélioré vos données de terrain. Les tests en laboratoire peuvent passer à côté de la variabilité des conditions réelles du réseau qui fait toute la valeur de cette stratégie.