Dans le web sur lequel nous surfons aujourd’hui, les polices d’écriture sont devenues presque aussi incontournables que les images. Il est rare de croiser un site qui n’utilise pas ses propres ensembles de polices d’écriture, et cela quelle que soit son activité.
Or, qu’on se le dise : cela impacte négativement les temps de chargement. Voyons les mécanismes qui rendent l’utilisation de fontes hébergées en ligne coûteuse, et comment il est possible d’optimiser le processus pour répondre aux attentes des internautes.
Les polices d’écriture, nouvelle forme d’expression du web
Les polices d’écriture sont devenues une forme d’expression à part entière dans la conception de sites web. Elles sont utilisées pour transmettre l’identité visuelle d’une entreprise et contribuent à renforcer son image de marque.
À travers son empattement, son crénage ou encore son interlignage, chaque police reflète les valeurs d’un site et renseigne les utilisateurs sur ses intentions. C’est la raison pour laquelle une entreprise de services financiers et une société de loisirs ne se tourneront généralement pas vers les mêmes typographies.
Les polices d’écriture constituent un élément clé de la stratégie de communication visuelle d’une entreprise. S’il y a déjà un large choix parmi les plus de 1500 polices hébergées sur Google Fonts, nombreuses sont les marques à se tourner vers des catalogues plus Premium, comme celui d’Adobe Fonts (ex-Typekit), ou encore à adopter des fontes achetées directement auprès de leur designer. Mieux encore, certaines conçoivent leurs propres webfonts afin de s’aligner parfaitement avec leur logo, à l’image de l’hébergeur Kinsta entre autres.
Associées à la quasi-infinité de modifications rendues possibles grâce à CSS, les webfonts peuvent être utilisées pour créer un environnement visuel cohérent avec les couleurs, les images et les autres éléments de design d’un site. Ombres portées, reliefs voire même animations en font un élément de design extrêmement puissant et versatile. Malheureusement, ces atouts indéniables ont un coût que chaque utilisateur paie en visitant votre site.
Un impact direct et concret sur les métriques de performance
L’impact des polices d’écriture sur la performance est très largement sous-estimé. Trop nombreuses, mal choisies ou non optimisées, elles peuvent pénaliser de façon considérable l’Expérience Utilisateur et les métriques de performance, Core Web Vitals en tête.
Le LCP très fortement impacté
L’explication vient du mécanisme de priorisation des ressources intégré aux navigateurs : pour être en mesure d’afficher rapidement les textes, les webfonts sont appelées avec une priorité très élevée. Leur téléchargement consomme ainsi de la bande passante critique et entre en concurrence avec d’autres ressources clés comme les feuilles de styles, les images ou… d’autres webfonts !
Le Largest Contentful Paint (LCP) est en conséquence très sensible au volume de fichiers de police appelés. Plusieurs « erreurs » très courantes impactent directement le LCP, soit parce que le poids des polices augmente, soit parce que leur téléchargement est soumis à des latences :
- Nombre trop élevé : on ne parle pas là du nombre de webfonts différentes mais du nombre de fichiers de fontes nécessaires à l’affichage d’une page. Chaque variation de graisse (de 100 à 900) et chaque version italique qui s’y rattache potentiellement constituent un fichier distinct (exception faite des variable fonts). Il est crucial de limiter le nombre de fichiers à 4 ou 5 maximum, toutes polices confondues.
- Poids trop élevé : les fichiers de polices peuvent intégrer un nombre variable de caractères, appelés « glyphes ». Or, il est courant de voir des sites charger des fichiers qui incluent des subsets comme « Greek », « Russian » ou encore « Cyrillic » alors qu’ils affichent des textes en français ou en anglais.
- Format inadapté : avec les formats Woff et Woff2, il est possible de supporter plus de 98% des navigateurs utilisés. Ces formats, conçus spécifiquement pour les webfonts, se suffisent ainsi à eux-mêmes et remplacent efficacement les formats anciens et/ou spécifiques comme l’eot (Internet Explorer), le svg (Safari) et le ttf. Trop de sites continuent à utiliser ces derniers, avec un impact majeur sur le poids des ressources téléchargées.
- Hébergement distant : utiliser des polices d’écriture hébergées sur les cdn de Google Fonts ou Typekit génère d’importantes latences. Pour télécharger ces ressources, le navigateur doit en effet se connecter au serveur distant et effectuer une résolution dns, une connexion puis une négociation SSL. Cela représente entre 500 ms et une seconde de délai supplémentaire.
- Chaînes de requêtes : pour télécharger rapidement les fichiers de fontes nécessaires, le navigateur doit être en mesure de les détecter le plus rapidement possible au chargement initial des pages. Or, bien souvent, les déclarations @font-face sont faites au sein de fichiers CSS appelés depuis les pages, retardant leur découverte de plusieurs centaines de millisecondes.
Des risques de CLS élevés
Au-delà des problématiques inhérentes aux fichiers de fontes en eux-mêmes, les webfonts peuvent être à l’origine d’importants Layout Shifts. Le comportement de type font-display: swap, qui permet aux utilisateurs de démarrer la lecture des textes avant que les fichiers de fontes ne soient téléchargés, peut en effet conduire à des variations d’occupation d’espace.
Généralement mineurs sur les paragraphes de textes, les décalages horizontaux ou verticaux peuvent être plus importants sur les éléments de titres : lorsqu’un mot passe à la ligne suivante sur un texte de grande taille, cela représente rapidement plusieurs dizaines de pixels. L’impact sur l’Expérience Utilisateur est alors problématique.
Ces mouvements sont pris en compte au sein des Core Web Vitals comme du « Cumulative Layout Shift », ou CLS.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Font-display : arbitrer entre lisibilité immédiate et stabilité visuelle
Chaque déclaration @font-face peut embarquer un descripteur font-display, qui dicte au navigateur le comportement à adopter pendant le téléchargement d’une webfont : masquer le texte, un phénomène connu sous le nom de FOIT (« Flash Of Invisible Text »), ou afficher immédiatement une police de substitution, le fameux FOUT (« Flash Of Unstyled Text »). Ce choix, documenté en détail sur MDN, conditionne directement l’équilibre entre vitesse d’affichage des textes et stabilité visuelle de la page.
Cinq valeurs aux comportements bien distincts
Le descripteur accepte cinq valeurs, qui combinent différemment deux périodes : la période de blocage, pendant laquelle le texte reste invisible, et la période d’échange, pendant laquelle la police de fallback peut encore être remplacée par la webfont :
- auto : laisse le navigateur décider. Dans la quasi-totalité des cas, cela équivaut à block.
- block : le texte reste invisible pendant une durée pouvant atteindre 3 secondes, puis la police de fallback s’affiche en attendant la webfont. C’est le pire choix possible pour le LCP sur une connexion lente.
- swap : la police de fallback s’affiche dès le premier rendu, puis la webfont la remplace dès son arrivée. Le texte est immédiatement lisible, au prix d’un risque de Layout Shift lors du basculement.
- fallback : un compromis entre les deux, avec une période de blocage d’environ 100 ms et une période d’échange d’environ 3 secondes. Si la webfont arrive trop tard, elle est tout simplement ignorée pour la page en cours.
- optional : après la même période de blocage d’environ 100 ms, la webfont n’est utilisée que si elle est déjà disponible, typiquement en cache. Sinon, la police de fallback est conservée pour toute la durée de la navigation.
Notre stratégie selon le type de police
Pour les polices textuelles, nous recommandons systématiquement font-display: swap, combiné à une fonte de fallback ajustée comme décrit plus bas : le contenu est lisible dès le premier rendu, ce qui préserve le LCP, et le Layout Shift du basculement est neutralisé. C’est d’ailleurs le comportement servi par défaut par Google Fonts depuis 2019.
@font-face {
font-family: "Inter";
src: url("/fonts/inter-regular.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}Pour les polices d’icônes en revanche, swap est contre-productif : la police de fallback ne contient pas les glyphes attendus, et l’utilisateur voit apparaître des carrés vides ou des caractères incohérents le temps du chargement. La valeur block est ici plus pertinente, l’icône restant invisible quelques instants avant de s’afficher correctement. Rappelons au passage que ces polices d’icônes sont souvent très lourdes au regard des quelques glyphes réellement utilisés, et qu’un simple jeu de SVG inline les remplace avantageusement dans la plupart des cas.
Enfin, pour une police fortement identitaire chargée sur un élément critique, un titre hero par exemple, la combinaison de font-display: optional et d’un préchargement constitue l’option la plus sûre : web.dev la présente comme le moyen le plus simple d’éliminer tout Layout Shift lié aux fontes, la webfont étant soit affichée d’emblée, soit remplacée définitivement par son fallback.
Des outils et techniques d’optimisation efficaces
Comme bien souvent lorsqu’il s’agit de web performance, une partie des techniques d’optimisation est de l’ordre du bon sens : si les polices d’écriture impactent les temps de chargement, il convient de réduire leur utilisation. De même, s’il existe des formats légers adaptés spécifiquement au web, il faut tout simplement les utiliser. Et si leur hébergement distant génère des latences, il convient de les héberger localement, tout simplement (adieu Google Fonts, donc).
Pour bien d’autres problématiques en revanche, il existe des outils, parfois assez techniques, pour en réduire l’impact. Voici les trois que nous utilisons quotidiennement.
Subsetting optimal des webfonts
Plusieurs outils permettent de réduire le poids des fichiers de fontes qui incluent des glyphes inutiles :
- Font Subsetter du site everythingfonts.com : en ligne et très simple à utiliser, il est idéal pour les profils les moins techniques et les plus pressés.
- Glyphhanger, basé sur fonttools, qui offre beaucoup plus de possibilités mais doit être installé localement et configuré en ligne de commandes.
Ces différents outils partagent un point commun dans leur fonctionnement : on définit ce qui doit être conservé, pas ce qui doit être supprimé. Pour afficher des textes en français ou en anglais, il suffira généralement d’activer les deux sous-ensembles « Basic Latin » et « Latin-1 Supplement ».
Cette technique permet de réduire le poids des fichiers de fontes d’un facteur de 2 jusqu’à 7, en fonction de ce qui a été mis en ligne initialement. L’impact sur le LCP peut ainsi être majeur.
Unicode-range, le subsetting à la carte
Le subsetting devient encore plus puissant lorsqu’il est combiné au descripteur unicode-range. Celui-ci permet d’indiquer au navigateur les plages de caractères couvertes par chaque fichier de fonte : le fichier n’est alors téléchargé que si la page affiche effectivement au moins un caractère de la plage concernée, comme l’explique la documentation MDN.
C’est exactement le mécanisme qu’exploite Google Fonts en découpant chaque police en sous-ensembles « latin », « latin-ext », « cyrillic » ou encore « greek ». Voici à quoi ressemblent des déclarations de ce type :
/* Caractères latins de base : téléchargé sur toutes les pages */
@font-face {
font-family: "Manrope";
src: url("/fonts/manrope-latin.woff2") format("woff2");
font-display: swap;
unicode-range: U+0000-00FF, U+0152-0153, U+2019, U+20AC;
}
/* Latin étendu : téléchargé uniquement si nécessaire */
@font-face {
font-family: "Manrope";
src: url("/fonts/manrope-latin-ext.woff2") format("woff2");
font-display: swap;
unicode-range: U+0100-024F, U+1E00-1EFF;
}Sur un site multilingue, cette approche évite de faire payer aux visiteurs français le poids des glyphes polonais ou tchèques, tout en garantissant un affichage correct de chaque langue. Attention toutefois à découper intelligemment : chaque plage supplémentaire correspond à une requête potentielle, et un découpage trop fin finit par multiplier les fichiers à télécharger au lieu d’en réduire le poids.
Définition de font-stacks optimisées
Pour éviter les comportements tels que ceux illustrés plus haut sur le site de Courrier International, il est essentiel de définir des polices de fallback les plus proches visuellement des webfonts finales au sein de la font-stack.
Une safe-font proche visuellement
La bonne pratique consiste, dans un premier temps, à choisir la « safe font » la plus pertinente parmi les neuf existantes. Il s’agit de polices d’écriture disponibles dans tous les navigateurs, quel que soit le système d’exploitation :
- Arial
- Verdana
- Tahoma
- Trebuchet MS
- Times New Roman
- Georgia
- Courier New
- Brush Script MT
- Impact
Une police de fallback direct optimisée
Malgré la sélection d’une police système proche, il est rare que l’espace occupé à l’écran soit identique. La solution, pour supprimer définitivement tout risque de Layout Shift lors du basculement de l’une à l’autre, est la mise en place d’une fonte de fallback optimisée. Cela consiste à générer une police virtuelle, à partir d’une safe font, pour la rendre encore plus proche visuellement.
La bonne nouvelle, c’est que les navigateurs proposent désormais des descripteurs CSS dédiés à cet ajustement, dont le fonctionnement est décrit en détail dans l’article de Katie Hempenius sur les font fallbacks. Pour générer votre fonte de fallback, vous pouvez vous reposer sur un outil en ligne comme le Fallback Font Generator de Screenspan, qui permet d’ajuster visuellement la superposition des deux polices.
Dans les deux cas, vous obtiendrez au final un code CSS ressemblant à cela :
@font-face {
font-family: "Montserrat-fallback";
size-adjust: 113.38999999999997%;
ascent-override: 83%;
src: local("Arial");
}
body {
font-family: Montserrat, "Montserrat-fallback", Arial, sans-serif;
}Ce code s’appuie sur une famille de descripteurs CSS relativement récents et supportés par l’ensemble des navigateurs modernes : size-adjust, qui redimensionne les glyphes de la police de fallback (documentation MDN), ainsi que ascent-override, descent-override et line-gap-override, qui alignent les métriques verticales (hauteur au-dessus et en dessous de la ligne de base, interligne) sur celles de la webfont cible. Correctement calibrés, ces quatre descripteurs font coïncider au pixel près l’espace occupé par les deux polices, et ramènent à zéro le CLS lié au basculement.
Préchargement des principaux fichiers de police
La troisième et dernière optimisation que nous partageons avec vous permet de réduire drastiquement le LCP sur les pages où il est constitué de textes (titre ou paragraphe), mais aussi le CLS pour les utilisateurs avec les connexions les plus rapides. Elle repose sur le Resource Hint « Preload », qui permet de forcer le navigateur à télécharger certaines ressources très tôt, avant même leur découverte.
Si vous avez bien lu ce qui précède, il s’agit de la solution la plus pertinente pour réduire la latence liée aux chaînes de requêtes : au lieu d’attendre que le navigateur découvre par lui-même le fichier de fonte dont il a besoin, on le lui sert sur un plateau d’argent. La mise en oeuvre de preloads de ce type est assez simple avec des polices hébergées localement.
Attention toutefois : on ne précharge qu’un seul fichier par variation de graisse, et uniquement dans sa version la plus légère et moderne, soit le Woff2 idéalement. Voici un exemple de code html à intégrer en entête :
<link rel="preload" as="font" href="https://agencewebperformance.fr/wp-content/themes/generateperf/fonts/inter-variable/inter-variable.woff2" crossorigin>Les variable fonts, une consolidation salutaire
Terminons ce tour d’horizon par la technologie qui a le plus profondément changé notre façon d’intégrer des polices : les variable fonts, ou polices variables. Là où une famille classique nécessite un fichier par graisse et par style, une police variable regroupe dans un fichier unique un continuum complet de variations, décrites le long d’axes normalisés : la graisse (wght), la chasse (wdth), l’inclinaison (slnt), l’italique (ital) et la taille optique (opsz), comme le détaille le guide MDN dédié.
Moins de requêtes, plus de liberté typographique
Le bénéfice performance est immédiat : au lieu de mettre en concurrence quatre, six voire huit fichiers appelés à haute priorité au chargement initial, on n’en télécharge plus qu’un ou deux (un pour le romain, un pour l’italique). Un fichier variable pèse certes plus lourd qu’un fichier statique isolé, mais nettement moins que la somme des fichiers qu’il remplace dès lors que trois graisses ou plus sont utilisées sur le site.
Le bénéfice est aussi créatif : toutes les graisses intermédiaires deviennent accessibles en CSS (font-weight: 550 par exemple), y compris en animation ou au survol, sans la moindre requête supplémentaire. Le support navigateur est aujourd’hui quasi universel, ce qui en fait une technologie parfaitement utilisable en production. C’est d’ailleurs un choix que nous faisons systématiquement dans le cadre de nos créations de sites performants.
Une déclaration CSS en plages de valeurs
La déclaration @font-face d’une police variable diffère peu de celle d’une police classique : on y renseigne simplement des plages de valeurs plutôt que des valeurs fixes. Le descripteur font-weight accepte ainsi deux bornes, et la syntaxe moderne tech(« variations ») permet de signaler aux navigateurs que le fichier embarque des variations :
@font-face {
font-family: "Inter";
src: url("/fonts/inter-variable.woff2") format("woff2") tech("variations"),
url("/fonts/inter-variable.woff2") format("woff2-variations");
font-weight: 100 900;
font-display: swap;
}Une fois cette déclaration en place, chaque font-weight utilisé dans les feuilles de style du site puise dans le même fichier, sans requête additionnelle ni graisse synthétisée approximativement par le navigateur.
Générer un fichier variable optimal avec fonttools
Les fichiers variables distribués par les fonderies embarquent souvent bien plus que nécessaire : axes exotiques, graisses extrêmes, alphabets complets. Pour en tirer le meilleur, nous les retravaillons systématiquement avec fonttools, la boîte à outils Python de référence en matière de manipulation de fontes, déjà évoquée plus haut au sujet du subsetting.
La démarche consiste à instancier une version réduite de la police, par exemple en ne conservant que les graisses de 300 à 800 sur l’axe wght, puis à générer un fichier Woff2 limité aux plages de caractères utiles :
pip install fonttools brotli
fonttools varLib.instancer font.ttf wdth=100 wght=300:800
pyftsubset font-instance.ttf --flavor=woff2 --layout-features=kern,liga,clig --output-file="font.woff2" --unicodes="U+0020-007E,U+00A0-00FF,U+0152-0153,U+2019,U+20AC"Le fichier obtenu cumule l’intégralité des optimisations décrites dans cet article : un format moderne, un subsetting adapté à la langue du site, un poids minimal et une flexibilité typographique totale. Il ne reste plus qu’à l’héberger localement, à le précharger et à lui associer une fonte de fallback ajustée pour obtenir un affichage des textes à la fois immédiat et parfaitement stable.
Un site rapide et réactif
Les polices d’écriture peuvent considérablement affecter la performance de votre site web, mais il est possible de les optimiser pour en minimiser l’impact. En suivant les meilleures pratiques et en utilisant les outils appropriés, vous pouvez garantir que votre site web sera rapide et réactif pour tous les utilisateurs, indépendamment des polices d’écriture que vous choisissez.
Dans le cadre de nos prestations d’optimisation de la performance, nous mettons en oeuvre ces bonnes pratiques en complément de dizaines d’autres. Si vous avez besoin d’un accompagnement professionnel pour améliorer la performance de votre site, nous vous invitons à nous solliciter. Et si vous préférez commencer par identifier précisément les faiblesses de vos pages, notre audit de web performance constitue le point de départ idéal.
