On nous a collé une réputation de machine à ralentir les pages. Google Fonts, le DNS externe, le fichier CSS qui bloque le rendu, la brique de plus dans la cascade critique… J’ai déjà entendu un client exiger qu’on supprime toutes les polices Google de son WordPress « parce que ça fait chuter le score Lighthouse ». Sauf que le problème, ce n’est pas la fonte elle-même, c’est la manière paresseuse dont elle est intégrée. Sur un WordPress standard, la chaîne de chargement d’une typographie tierce peut coûter entre 0,5 et 1,2 seconde de LCP si personne n’a retouché le code généré par le thème.
J’ai mesuré l’écart sur un site de test avec GeneratePress, une connexion 4G throttled et un cache chaud côté serveur. Version de base, le thème balance un @import vers fonts.googleapis.com dans son CSS : LCP à 3,1 s. J’ai rapatrié les deux fontes en woff2, je les ai déclarées dans un fichier CSS local préchargé avec font-display: swap et un fallback calibré. Même page, même serveur, même contenu : 2,4 s. Trois quarts de seconde grattés sans désactiver une seule fonte. Sur les Core Web Vitals, la fonte tierce n’est pas le problème : la chaîne de chargement laissée par défaut, si.
Pourquoi Google Fonts n’est pas lent, mais le @import de votre thème vous enterre
Le service Google Fonts sert les fichiers woff2 depuis un CDN mondial, compressés, avec un en-tête de cache agressif. Sur une page déjà construite, la latence réseau est marginale. Le vrai dommage vient du chemin critique : le navigateur découvre une feuille externe sur fonts.googleapis.com, doit résoudre le DNS, négocier le TLS, télécharger le CSS, le parser, puis seulement il peut déclencher le téléchargement des fontes. Pendant ce temps, le rendu du texte est bloqué si le font-display est absent ou réglé sur auto. Résultat, le navigateur affiche une page blanche sans texte jusqu’à réception de la ressource.
Sur WordPress, les thèmes amplifient ce défaut parce qu’ils placent l’appel aux fonts dans le CSS principal, parfois avec une directive @import qui force le navigateur à charger ce deuxième fichier avant de commencer le moindre rendu. On ne mesure plus un simple téléchargement de police, on mesure un pipeline qui bloque le First Contentful Paint. Sur un site non retouché, la ligne « Eliminate render-blocking resources » du rapport Lighthouse pointe presque toujours vers le CSS Google Fonts.
Héberger les polices localement : la méthode que je reproduis à chaque nouveau client
La solution la plus stable, celle qui fonctionne peu importe le thème, consiste à rapatrier les fichiers woff2 directement dans l’arborescence du thème enfant et à les déclarer avec une règle @font-face placée dans un fichier CSS chargé le plus tôt possible, sans requête externe.
Voici le canevas PHP que je glisse dans le functions.php du thème enfant :
function rm_local_fonts() {
$fonts_css = get_stylesheet_directory() . '/fonts/fonts.css';
if ( file_exists( $fonts_css ) ) {
wp_enqueue_style(
'rm-local-fonts',
get_stylesheet_directory_uri() . '/fonts/fonts.css',
array(),
filemtime( $fonts_css )
);
}
}
add_action( 'wp_enqueue_scripts', 'rm_local_fonts', 5 );La clé ici, c’est la priorité 5. Beaucoup de thèmes enqueuent leur CSS principal avec la priorité 10 par défaut. En déclarant les polices à 5, je garantis qu’elles arrivent plus haut dans le <head>, ce qui donne au navigateur l’information de fonte avant même qu’il ne rencontre les sélecteurs qui en ont besoin. Ensuite, le fichier fonts.css contient une règle comme celle-ci :
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('inter-regular.woff2') format('woff2');
}Pour télécharger les fontes au bon format, j’utilise l’outil google-webfonts-helper, qui permet de sélectionner les variantes utilisées et de récupérer une archive prête à déployer. Je ne garde que les woff2, supporté par 98 % des navigateurs aujourd’hui. Cette méthode coupe l’intégralité des requêtes tierces liées à Google Fonts et retire un blocage du chemin critique. Elle s’accompagne presque toujours d’une amélioration du LCP comprise entre 300 et 500 ms sur mobile, mesurée via les données terrain de la Search Console.
💡 Conseil : Si vous utilisez un thème qui propose une option « Google Fonts », désactivez-la avant d’enqueuer votre propre CSS, sinon vous accumulez deux chargements concurrents qui peuvent se marcher dessus.
Le font-display: swap sans size-adjust crée un chantier de CLS
Activer swap, c’est autoriser le navigateur à afficher immédiatement le texte dans une police système pendant que la fonte personnalisée se charge. C’est la recommandation standard contre le Flash of Invisible Text. Mais si la police de fallback a des métriques différentes, le changement de fonte une fois la ressource chargée déplace l’ensemble du layout, et le CLS grimpe.
Avec font-display: swap, j’ajoute systématiquement un bloc de compensation via la propriété @font-face size-adjust ou, plus anciennement, font-size-adjust et ascent-override / descent-override. Avec Inter sur system-ui (Mac) et sans ajustement, le passage de la fallback à Inter provoque un saut vertical d’environ 3 à 4 pixels par ligne. Sur un paragraphe de 5 lignes, le pic de CLS dépasse 0,15.
Voici le fragment que j’ajoute systématiquement :
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('inter-regular.woff2') format('woff2');
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}Les pourcentages se calibrent en comparant les métriques fonte personnalisée vs fallback dans l’onglet « Fonts » des DevTools. Une fois en place, le CLS lié aux polices retombe à zéro. Sans le temps de calibrer les overrides, optional reste plus sûr, quitte à priver certains utilisateurs de la fonte personnalisée.
Le petit détail qui tue le cache : Access-Control-Allow-Origin
Quand on héberge les polices en local sur un WordPress servi par un CDN ou un sous-domaine pour les assets, le navigateur applique la politique cross-origin et bloque le téléchargement si le serveur n’envoie pas le bon en-tête CORS. J’ai perdu une demi-journée sur un site qui servait ses woff2 depuis cdn.client.com sans les en-têtes adaptés. Résultat, les polices ne se chargeaient pas sous Chrome et Firefox, mais passaient en local.
Le remède côté Apache tient en une ligne dans le .htaccess – ou l’équivalent Nginx – à placer dans le répertoire des fontes :
<IfModule mod_headers.c>
<FilesMatch "\.(woff2|woff|ttf)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>Sur Nginx, c’est un add_header dans le bloc location. Si vous avez déjà vu le message « CORS policy » dans la console sur un site qui semblait pourtant fonctionner, c’est que vous aviez la fonte installée en local sur votre machine.
Les plugins « Google Fonts » qu’on a testés ajoutent plus de requêtes qu’ils n’en retirent
Trois plugins audités, trois manières de rater le sujet. Le premier réinjecte un CSS via admin-ajax pour détecter les fontes utilisées : XHR superflue, CSS non cacheable. Le deuxième héberge en local mais déclare toutes les variantes téléchargées, +300 Ko inutiles. Le troisième remplace le @import par un <link> asynchrone avec onload : le rendu du texte recule encore.
Ce qui change en 2026 côté Google Fonts (et ce qui ne change pas)
Google a annoncé cette année un brotli dynamique sur les woff2 et un TTFB réduit sur les POP européennes. Sur une bonne connexion, ça grappille 50 à 80 ms de LCP, soit dix fois moins que ce que rapporte l’hébergement local préchargé. Le DNS et le TLS restent dans le chemin critique d’une ressource qui, structurellement, devrait être disponible avant le premier rendu.
Côté navigateurs, la propriété raccourcie size-adjust se généralise dans @font-face et remplace ascent-override, descent-override et line-gap-override. WordPress 6.5 embarque par ailleurs une API wp-fonts qui déclare les fontes locales sans CSS manuel, à condition de lui adjoindre le préchargement via wp_preload_resources.
Questions fréquentes
Faut-il désactiver complètement Google Fonts si l’on vise un score Lighthouse parfait ? Pas nécessairement. On obtient 100 en Performance avec des polices locales bien préchargées. L’hébergement externe, même optimisé, rend le 100 plus fragile à cause du préconnect DNS requis et de l’absence de contrôle sur le cache. Pour un score parfait contractuel, l’hébergement local s’impose. Sinon, un monitoring des Core Web Vitals de terrain reste plus pertinent qu’un score de lab.
Est-ce que cette technique fonctionne aussi avec Adobe Fonts ou les polices Typekit ?
Le principe de rapatriement local ne s’applique pas à Adobe Fonts, car leur licence impose un chargement depuis leur CDN pour garantir le comptage des pages vues. Dans ce cas, vous devez conserver la requête externe, mais vous pouvez quand même précharger le CSS Adobe et appliquer size-adjust sur le fallback pour limiter le CLS. La logique reste identique : la police externe n’est pas le problème, c’est l’absence de maîtrise de son chargement qui coûte cher.
Mon site utilise Elementor, puis-je appliquer cette méthode ? Oui, Elementor charge souvent les Google Fonts via son propre système. La procédure : un thème enfant, l’option « Load Google Fonts » désactivée dans les réglages Elementor, puis le code PHP de l’article. Le contrôle revient côté thème sans casser le constructeur visuel.
