Comment héberger des polices localement au lieu d’utiliser Google Fonts

Pourquoi auto-héberger Google Fonts ?

Google Fonts a rendu la bonne typographie facile à mettre en place. Ajoutez une feuille de style, choisissez quelques graisses, publiez la page. Pendant des années, c’était le choix par défaut raisonnable pour les petites équipes.

Le compromis, c’est que le navigateur de chaque visiteur contacte un service tiers pour récupérer le CSS des polices et les fichiers de police. Cela a deux conséquences.

Premièrement, cela ajoute une dépendance externe au rendu. Si le CSS de la police est lent, bloqué ou indisponible dans la région ou sur le réseau d’un utilisateur, votre page attend ou se rabat sur une police de secours.

Deuxièmement, cela soulève une question de confidentialité. Une requête de police peut révéler à un tiers l’adresse IP de l’utilisateur, son user agent, le contexte de la politique de référent et des informations de synchronisation. Google Fonts indique qu’il ne définit pas de cookies via la Fonts API, mais « pas de cookies » ne signifie pas « pas de données personnelles ». En vertu du RGPD, une adresse IP peut toujours être une donnée personnelle selon le contexte.

L’auto-hébergement des polices n’est pas automatiquement obligatoire pour chaque site web, et ceci ne constitue pas un avis juridique. Mais pour les sites européens, les sites du secteur public, la santé, l’éducation, la finance ou toute équipe qui cherche à réduire les requêtes inutiles vers des tiers, l’hébergement local est généralement le choix le plus propre.

C’est aussi souvent un gain de performance lorsqu’il est bien fait. Le piège tient dans « bien fait ». Copier six fichiers de police dans /assets/fonts/ et les charger tous sur chaque page peut être pire que d’utiliser le service hébergé. Si vous voulez le contexte plus large des performances, notre article précédent sur les raisons pour lesquelles les polices web restent le gain de performance le plus facile sur la plupart des sites couvre les schémas de gaspillage les plus courants.

Ce qui change quand vous auto-hébergez

Lorsque vous utilisez Google Fonts de la manière habituelle, votre page fait ceci :

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

Le navigateur demande d’abord le CSS à fonts.googleapis.com, puis télécharge les fichiers de police depuis fonts.gstatic.com.

Lorsque vous auto-hébergez, votre page doit demander à la fois le CSS et les fichiers de police depuis votre propre domaine :

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Cela supprime la requête de police vers un tiers. Cela vous rend aussi responsable du choix des formats de fichier, des en-têtes de cache, des polices de secours et des mises à jour.

Cette responsabilité mérite d’être prise au sérieux. Les polices se trouvent sur le chemin critique du rendu. Une mauvaise configuration des polices peut provoquer du texte invisible, des décalages de mise en page et un premier rendu lent.

Étape 1 : auditez ce que vous utilisez réellement

Avant de télécharger quoi que ce soit, dressez la liste des familles de polices, graisses, styles et jeux de caractères dont votre site a réellement besoin.

Un site marketing typique peut avoir besoin de :

• Regular 400 pour le texte courant
• Semibold 600 ou bold 700 pour les titres et les boutons
• Italic 400 uniquement si le design utilise vraiment l’italique
• Jeu de caractères latin uniquement, sauf si le site prend en charge davantage de langues

Méfiez-vous des anciens réglages par défaut des design systems. De nombreux sites chargent 300, 400, 500, 600, 700, des italiques et plusieurs scripts parce que quelqu’un les a sélectionnés une fois dans un sélecteur de polices.

Dans les DevTools du navigateur, ouvrez le panneau Network, filtrez par « font », rechargez la page et vérifiez quels fichiers sont demandés. Inspectez ensuite votre CSS pour repérer l’usage de font-weight. Si votre CSS n’utilise jamais 300, n’hébergez pas 300.

Si vous évaluez l’impact plus tard, Lighthouse peut aider, mais ne traitez pas son score comme toute l’histoire. Utilisez-le comme un outil de diagnostic, pas comme un juge. Nous avons un guide séparé sur la lecture d’un rapport Lighthouse sans paniquer, utile au moment de prioriser les corrections liées aux polices.

Étape 2 : téléchargez les bons fichiers de police

Google Fonts propose des polices open source. Vous pouvez les télécharger depuis le site Google Fonts ou depuis le dépôt du projet de police concerné. Vérifiez la licence, mais la plupart des Google Fonts sont distribuées sous des licences ouvertes telles que la SIL Open Font License ou l’Apache License.

Pour le web, privilégiez WOFF2. Il est largement pris en charge par les navigateurs modernes et généralement beaucoup plus léger que TTF ou OTF. En 2026, servir directement du TTF aux navigateurs se justifie rarement pour les sites web publics.

Une structure de répertoires raisonnable ressemble à ceci :

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Utilisez des noms de fichiers descriptifs. Six mois plus tard, font.woff2 sera agaçant. inter-latin-600.woff2 est banal et utile.

Si votre site utilise un système de build, conservez les polices sources dans un emplacement clair et laissez le pipeline de build copier les fichiers optimisés dans le répertoire public des assets.

Étape 3 : créez des sous-ensembles de polices quand c’est pertinent

Le sous-ensemble consiste à supprimer les caractères dont vous n’avez pas besoin. Une police complète peut inclure le latin, le cyrillique, le grec, le vietnamien, des symboles et de nombreuses fonctionnalités OpenType. Si votre landing page uniquement en anglais n’a besoin que de caractères latins, un sous-ensemble peut être considérablement plus léger.

Il existe deux approches courantes :

1. Utiliser un sous-ensemble préconstruit fourni par le fournisseur de police ou le dépôt.
2. Générer votre propre sous-ensemble avec un outil de police tel que pyftsubset de fonttools.

Pour de nombreuses équipes, les sous-ensembles latins préconstruits suffisent. Les sous-ensembles personnalisés sont utiles lorsque vous avez des pages très contraintes, comme une page de campagne unique avec un texte limité, ou une interface produit avec une couverture de caractères prévisible.

Soyez prudent avec les sites multilingues. Les glyphes manquants entraînent un mélange avec des polices de secours, ce qui peut paraître cassé et nuire à la lisibilité. Si vous prenez en charge plusieurs langues, associez les sous-ensembles de polices aux routes linguistiques plutôt que d’imposer partout un minuscule sous-ensemble.

Étape 4 : écrivez vos règles @font-face

Une configuration locale minimale ressemble à ceci :

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Quelques détails comptent ici.

Utilisez font-display: swap pour la plupart des sites de contenu. Cela indique au navigateur d’afficher rapidement le texte avec une police de secours, puis de remplacer cette police par la police web lorsqu’elle arrive. Cela évite la pire version du FOIT : le flash de texte invisible.

Définissez une pile de polices de secours explicite. Si la police personnalisée échoue, les utilisateurs doivent tout de même obtenir un texte lisible. Les polices de secours ne sont pas une réflexion après coup ; elles font partie du design. Si vous devez revoir les tailles, la longueur des lignes et les choix de texte courant, commencez par un guide pratique de la typographie lisible sur le web moderne.

Faites correspondre correctement les graisses. Si votre CSS demande font-weight: 500 mais que vous ne définissez que 400 et 700, le navigateur peut synthétiser une graisse intermédiaire. Ce n’est pas toujours terrible, mais le résultat peut sembler incohérent.

Étape 5 : supprimez les appels externes à Google Fonts

Après avoir ajouté le CSS de police local, supprimez les anciens appels distants de vos templates.

Recherchez :

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Vérifiez aussi :

• Les réglages de thème dans les plateformes CMS
• Les panneaux typographiques des page builders
• Les widgets tiers
• Les gestionnaires de balises
• Les anciens imports CSS comme @import url('https://fonts.googleapis.com/...')

Ce dernier cas est fréquent. Le @import CSS pour les polices est généralement moins bon pour les performances, car il retarde la découverte. Si vous auto-hébergez, définissez les polices directement dans votre CSS principal ou dans un fichier CSS de polices chargé tôt.

Le travail de confidentialité échoue souvent parce que les équipes corrigent le template évident mais manquent les scripts, widgets et intégrations héritées. Le même schéma apparaît dans le travail sur le consentement ; notre guide sur ce qui a changé pour les cookies en 2026 est un complément utile si vous réduisez plus largement votre surface de tiers.

Étape 6 : définissez les en-têtes de cache

Les fichiers de police sont des assets statiques. Ils doivent être mis en cache de manière agressive si leurs noms de fichiers sont versionnés ou hachés selon leur contenu.

Un bon en-tête de production est :

Cache-Control: public, max-age=31536000, immutable

N’utilisez une mise en cache immuable de longue durée que si l’URL change lorsque le fichier change. Par exemple :

inter-latin-400.a8f3c2.woff2

ou un chemin versionné :

/fonts/v2/inter-latin-400.woff2

Si vous écrasez /fonts/inter-latin-400.woff2 sans changer l’URL, certains utilisateurs peuvent conserver l’ancien fichier pendant longtemps. Cela ne pose pas de problème jusqu’au moment où cela en pose un. Le versionnement évite ce problème.

Servez également les polices avec le bon type MIME :

Content-Type: font/woff2

La plupart des plateformes d’hébergement modernes gèrent cela automatiquement, mais cela vaut la peine de le vérifier.

Étape 7 : envisagez de précharger uniquement la police critique

Le préchargement peut aider le navigateur à découvrir plus tôt une police importante :

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

Utilisez cela avec parcimonie. Préchargez la police principale du texte visible au-dessus de la ligne de flottaison, pas chaque graisse de police. Trop de préchargements entrent en concurrence avec le CSS, les images et JavaScript.

Même pour les polices de même origine, incluez crossorigin sur les préchargements de police. Le chargement des polices utilise le mode CORS, et l’omettre peut provoquer des téléchargements en double dans certaines configurations.

Si vous n’êtes pas sûr, testez. Ne reproduisez pas des préchargements par mimétisme simplement parce qu’une checklist l’a dit.

Étape 8 : testez la confidentialité et les performances

Les tests sont simples.

Ouvrez DevTools, rechargez la page avec le cache désactivé et filtrez le panneau Network sur :

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Vous devriez voir les fichiers de police servis depuis votre propre domaine, sans requêtes Google Fonts.

Testez ensuite avec un cache froid et un cache chaud. Lors de la première visite, les polices doivent être téléchargées une fois. Lors des visites suivantes, elles doivent venir du cache mémoire ou disque selon le navigateur.

Vérifiez les décalages de mise en page lorsque la police est remplacée. Si les titres sautent, les métriques de votre police de secours diffèrent trop de celles de la police web. Vous pouvez réduire le décalage visible en choisissant une police de secours plus proche ou en utilisant des ajustements CSS plus récents des métriques de police, tels que size-adjust, ascent-override, descent-override et line-gap-override. Ce sont des techniques plus avancées, mais utiles pour des interfaces soignées.

Enfin, testez les pages en navigation privée ou avec des bloqueurs de contenu activés. L’un des avantages de l’auto-hébergement est que les outils de confidentialité sont moins susceptibles de bloquer accidentellement votre typographie.

Erreurs courantes à éviter

Héberger trop de graisses

C’est l’échec le plus courant. Deux graisses suffisent souvent. Trois sont généralement largement assez. Cinq sont un signal d’alerte de design system, sauf si vous avez une raison solide.

Oublier les italiques

Si votre contenu utilise une véritable emphase, chargez un vrai fichier italique. Les italiques synthétiques peuvent être médiocres, surtout dans les contenus éditoriaux longs.

Conserver l’ancien lien CSS Google

Cela annule l’intérêt de la migration. Après la migration, aucune requête de police ne doit aller vers Google, sauf si un autre composant l’injecte.

Servir les polices sans cache à long terme

L’auto-hébergement vous donne le contrôle. Utilisez-le. Les polices sont des candidates idéales pour de longues durées de cache.

Ignorer le travail juridique et documentaire

Si votre politique de confidentialité mentionnait auparavant Google Fonts ou le chargement de polices tierces, mettez-la à jour après la migration. Si vous maintenez un registre des traitements de données, mettez-le aussi à jour. Le changement technique et le dossier de conformité doivent être cohérents.

<!-- tool-cta:start -->

💡 Essayez ceci : Convertissez les fichiers TTF que vous avez téléchargés depuis Google Fonts en WOFF2 auto-hébergeable plus CSS avec Webfont Generator.

<!-- tool-cta:end -->

Une checklist de migration simple

1. Listez les familles de polices, graisses, styles et scripts que vous utilisez réellement.
2. Téléchargez les fichiers WOFF2 et confirmez la licence.
3. Créez des sous-ensembles de polices si le site a des besoins linguistiques limités.
4. Ajoutez des règles @font-face locales avec font-display: swap.
5. Supprimez toutes les références Google Fonts link, preconnect et @import.
6. Servez les polices depuis votre propre domaine avec des en-têtes de cache de longue durée.
7. Préchargez uniquement la police la plus importante au-dessus de la ligne de flottaison, si les tests le confirment.
8. Vérifiez dans DevTools qu’il ne reste aucune requête Google Fonts.
9. Mettez à jour la documentation de confidentialité si nécessaire.

L’auto-hébergement des polices n’est pas un travail spectaculaire. C’est le genre de petit nettoyage d’infrastructure qui réduit le risque de dépendance, améliore la posture de confidentialité et vous donne un rendu plus prévisible. Cela vaut généralement l’heure ou les deux heures nécessaires.