Héberger les Google Fonts en local : perf + RGPD

Le problème avec fonts.googleapis.com

Un matin, sur un site WordPress avec Elementor, le rapport PageSpeed affichait une ligne récurrente : “Réduire l’impact du code tiers” — pointant vers deux domaines Google, fonts.googleapis.com et fonts.gstatic.com. Rien de cassé, juste deux requêtes DNS supplémentaires, deux connexions TLS, et un petit délai avant que le texte s’affiche correctement (le fameux flash de texte invisible ou mal stylé). Sur ce site précis, désactiver l’appel externe et servir les polices depuis le serveur a suffi à gagner plusieurs centaines de millisecondes sur le LCP.

Ce guide t’explique pourquoi héberger tes Google Fonts en local règle deux problèmes à la fois — la performance et une zone grise RGPD — et comment le faire proprement, que tu sois sur WordPress avec un plugin ou en configuration manuelle.

Pourquoi c’est important : perf et RGPD

Quand ton site charge une police depuis fonts.googleapis.com, le navigateur du visiteur :

• résout un DNS supplémentaire vers un domaine Google ;
• ouvre une connexion TLS vers ce domaine ;
• télécharge un fichier CSS, puis les fichiers de police (souvent en .woff2) depuis fonts.gstatic.com — une troisième connexion.

Chaque connexion externe ajoute de la latence, surtout sur mobile ou avec une connexion moyenne. C’est exactement le type de ralentissement détaillé dans notre diagnostic de site lent tous CMS confondus : des dizaines de petites requêtes tierces qui, cumulées, plombent le LCP et les Core Web Vitals.

Côté RGPD, le sujet est plus nuancé qu’on ne le dit souvent. Charger des polices depuis les serveurs Google transmet l’adresse IP du visiteur à Google avant même qu’il n’ait interagi avec ton site ou accepté un quelconque cookie — un tribunal allemand (LG München) avait tranché en ce sens en 2022, et la CNIL recommande depuis d’éviter les appels à des ressources externes qui ne sont pas strictement nécessaires. Héberger les polices en local supprime ce transfert de données et simplifie ta conformité, sans attendre un consentement cookie pour un simple caractère typographique. Si tu veux creuser le sujet plus large de la conformité de ton site, notre article sur le RGPD et site web en 2026 détaille les autres points à vérifier.

Prérequis

Avant de commencer, assure-toi d’avoir :

• un accès à l’administration WordPress (ou à l’éditeur de ton thème/builder) ;
• un accès FTP/SFTP ou au gestionnaire de fichiers de ton hébergeur, si tu passes par la méthode manuelle ;
• la liste exacte des polices Google utilisées sur ton site (nom + graisses/styles réellement affichés) ;
• une sauvegarde récente du site avant toute modification de fichiers ou de plugins ;
• si tu utilises Elementor, WPBakery ou un autre builder visuel, vérifie où les polices sont déclarées (souvent dans les réglages globaux du thème ou du builder).

Étape 1 : identifier les polices réellement utilisées

Ouvre les outils de développement de ton navigateur (F12), onglet Réseau, filtre “Font” ou “CSS”, et recharge la page en navigation privée. Tu verras apparaître les requêtes vers fonts.googleapis.com avec le nom des familles de polices demandées (par exemple Poppins:wght@400;600;700).

Note précisément :

• le nom de chaque famille de police ;
• les graisses (400, 500, 600, 700…) et styles (normal, italique) réellement chargés.

Ne télécharge pas toutes les graisses “au cas où” — c’est souvent la cause d’un poids de page excessif. Une police en 3 graisses (regular, medium, bold) suffit dans 90 % des cas.

Étape 2 : choisir sa méthode (plugin ou manuelle)

Trois approches coexistent en 2026, avec des compromis différents :

Si ton site tourne déjà sous Astro plutôt que WordPress, la méthode manuelle est quasi obligatoire — il n’y a pas d’équivalent plugin, mais l’opération reste simple à intégrer au build.

Étape 3 : héberger en local avec OMGF (le plus simple)

OMGF (OMGF - Optimize My Google Fonts) reste en 2026 la solution la plus utilisée sur WordPress pour ce cas précis.

1. Installe et active le plugin OMGF depuis le répertoire WordPress.
2. Rends-toi dans Réglages > OMGF.
3. Le plugin scanne automatiquement ton site et détecte les appels à Google Fonts (thème, builder, plugins).
4. Il télécharge les fichiers de police sur ton serveur et génère le CSS @font-face correspondant.
5. Vérifie dans l’onglet “Test” que toutes les requêtes externes vers Google ont disparu.
6. Vide ton cache (plugin de cache + cache serveur si tu es sous LiteSpeed) et recharge la page en navigation privée pour confirmer.

Le principal avantage d’OMGF : il détecte aussi les polices chargées par des thèmes tiers ou des builders comme WPBakery, ce qui évite de manquer un appel externe caché dans un shortcode.

Étape 4 : héberger via Autoptimize

Si tu utilises déjà Autoptimize pour minifier CSS et JS, il propose une option native “Optimiser les Google Fonts” dans son onglet dédié :

1. Va dans Réglages > Autoptimize > Extra.
2. Dans la section Google Fonts, choisis l’option “Combiner et lier en tête” ou “Héberger localement” selon la version.
3. Enregistre, puis vide le cache Autoptimize et le cache de page.
4. Contrôle à nouveau dans l’onglet Réseau qu’aucune requête ne part vers fonts.googleapis.com.

Autoptimize est moins précis qu’OMGF sur la détection automatique des polices chargées par des builders complexes — s’il en manque, complète avec la méthode manuelle ci-dessous pour les cas résiduels.

Étape 5 : la méthode manuelle (contrôle total)

Pour un site sur mesure, un thème custom ou si tu veux éviter tout plugin supplémentaire :

1. Va sur Google Fonts, sélectionne ta police et les graisses nécessaires, télécharge les fichiers .woff2 (le format le plus léger et le plus compatible).
2. Dépose ces fichiers dans un dossier de ton thème, par exemple wp-content/themes/ton-theme/fonts/.
3. Ajoute dans ta feuille de style (ou un fichier CSS dédié) :

@font-face {
  font-family: 'Poppins';
  src: url('/fonts/poppins-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

4. Répète pour chaque graisse utilisée.
5. Utilise font-display: swap pour éviter que le texte reste invisible pendant le chargement — un point souvent lié aux soucis de lazy loading et de LCP.
6. Précharge la police principale dans le <head> avec <link rel="preload" as="font" type="font/woff2" href="/fonts/poppins-regular.woff2" crossorigin> pour accélérer son affichage.

Étape 6 : mesurer l’impact réel sur PageSpeed

Une fois la migration faite :

1. Relance un test PageSpeed Insights (ou Lighthouse en local) avant/après.
2. Vérifie dans l’onglet Réseau que le nombre de domaines tiers contactés a diminué.
3. Regarde spécifiquement le LCP et le CLS (le “saut” visuel dû au changement de police disparaît souvent aussi).
4. Si ton hébergement mutualisé sert mal les fichiers statiques, vérifie ta configuration de cache LiteSpeed ou les directives PHP qui peuvent ralentir la livraison des assets.

L’impact typique observé sur ce genre d’optimisation : suppression de 2 à 4 requêtes externes, gain de 100 à 400 ms sur le temps de chargement perçu, selon la latence réseau du visiteur et la qualité de l’hébergement — pas un miracle, mais un gain net et cumulable avec d’autres optimisations.

Pièges courants

• Oublier une graisse utilisée par un plugin. Un plugin d’avis clients ou de slider peut charger sa propre police Google en parallèle. Repasse l’onglet Réseau après la migration pour traquer les appels résiduels.
• Ne pas vider les caches. CSS Autoptimize, cache de page, cache serveur, CDN : un ancien fichier CSS pointant encore vers Google peut rester servi plusieurs jours.
• Charger trop de graisses “par sécurité”. Chaque graisse ajoute un fichier .woff2 à télécharger. Limite-toi à celles réellement affichées à l’écran.
• Format non optimisé. Privilégie systématiquement .woff2 : plus léger que .woff ou .ttf, supporté par tous les navigateurs modernes.
• Oublier le crossorigin sur le preload. Sans cet attribut, le navigateur télécharge la police deux fois (une pour le preload, une pour l’usage réel).
• Croire que ça règle tout le RGPD du site. Héberger les polices en local supprime un transfert de données précis, mais ne dispense pas d’une bannière de consentement pour Analytics, pixels publicitaires ou autres scripts tiers.

Sur un site déjà optimisé pour le cache et les images, ce genre de correctif ciblé se règle en moins d’une heure et reste l’un des rapports effort/gain les plus favorables en matière de performance web.