Quatre. C’est le nombre moyen de déclarations <link rel="preload"> pointant vers une police que l’on retrouve dans l’en-tête des thèmes premium les plus vendus. Certains montent à huit, en comptant les graisses regular, bold, italic et leurs variantes latin-ext. Chacune de ces lignes dit au navigateur : télécharge ce fichier tout de suite, avant même d’avoir terminé d’analyser la feuille de style.
Le problème ne saute pas aux yeux dans Lighthouse en conditions de laboratoire, sur un poste avec une connexion filaire rapide. Il devient flagrant sur le terrain, en 4G réelle, quand six requêtes prioritaires se disputent la même bande passante que l’image d’en-tête et la feuille de style principale. Le rendu du plus grand élément visible (LCP) recule au lieu d’avancer.
Ce qu’on voit sur le terrain
Le scénario se répète d’un projet à l’autre. Une extension de performance ou un thème ajoute automatiquement un bloc de préchargement dans le wp_head, censé « accélérer le rendu du texte ». Il liste toutes les polices utilisées par le thème, sans distinguer celle qui habille le titre visible immédiatement de celle qui ne sert que dans un widget de pied de page jamais visible au chargement.
- Quatre à huit balises
preloadpointant vers des fichiers.woff2de 15 à 40 ko chacun. - Aucune priorité différenciée entre la police du titre principal et celle des légendes secondaires.
- Un attribut
crossoriginparfois oublié, qui fait télécharger la police deux fois : une pour le préchargement, une pour l’usage réel.
Pourquoi le préchargement massif aggrave le LCP
Le navigateur applique un budget de priorité limité au tout début du chargement de page. En temps normal, il découvre la feuille de style, la parse, puis déclenche le téléchargement des polices réellement référencées dans les règles CSS visibles. Le préchargement court-circuite cette découverte : il force le téléchargement dès la lecture du <head>, avant même que le navigateur sache si la police sera utilisée au-dessus de la ligne de flottaison.
Avec une seule police ciblée, ce raccourci profite au rendu : le texte s’affiche avec la bonne typographie sans étape de repeinte. Avec quatre à huit polices, le raccourci devient un embouteillage. Le navigateur consacre sa bande passante initiale à des fichiers qui, pour la moitié d’entre eux, ne seront visibles qu’après un défilement, retardant d’autant le téléchargement de l’image ou du bloc de texte qui définit réellement le LCP.

Ce que fait réellement link rel="preload"
La spécification est claire sur ce point : preload ne fait qu’avancer le moment du téléchargement, il ne change ni la priorité réseau globale ni le nombre de connexions disponibles. Sur HTTP/2, les requêtes partagent la même connexion et se répartissent la bande passante ; multiplier les préchargements dilue donc la part de chacun, y compris celle de la ressource qui compte vraiment pour le LCP.
<!-- Ce que beaucoup de thèmes génèrent automatiquement -->
<link rel="preload" href="/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/fonts/inter-bold.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/fonts/inter-italic.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/fonts/inter-bold-italic.woff2" as="font" type="font/woff2" crossorigin>
La bonne méthode : cibler une seule police critique
Identifiez la police qui habille le titre ou le premier paragraphe visible sans défilement, celle qui compose réellement l’élément candidat au LCP. C’est la seule qui mérite un préchargement. Les autres graisses et styles se chargent normalement, via la feuille de style, quand le navigateur en a besoin.
add_action( 'wp_head', function () {
echo '<link rel="preload" href="' . esc_url( get_theme_file_uri( 'assets/fonts/inter-var.woff2' ) ) . '" as="font" type="font/woff2" crossorigin>';
}, 1 );
Cette fonction, accrochée à wp_head avec une priorité basse (1), place la balise tôt dans le document tout en ne ciblant qu’un seul fichier. Si le thème utilise une police variable, un seul fichier woff2 couvre l’ensemble des graisses, ce qui supprime d’un coup trois ou quatre préchargements superflus.
Vérifier l’attribut crossorigin
Une police est une ressource dite « anonyme » du point de vue CORS. Sans l’attribut crossorigin, le navigateur considère la requête de préchargement et la requête réelle comme deux ressources distinctes et télécharge le fichier deux fois. C’est l’erreur la plus fréquente relevée dans les audits, et la plus simple à corriger.
Mesurer avant et après
Le test le plus parlant se fait avec l’onglet réseau du navigateur, filtré sur les requêtes de type police, en simulant une connexion 4G. Comptez le nombre de fichiers de police lancés dans les deux premières secondes, puis comparez avec le moment où l’élément candidat au LCP finit de se peindre.
| Configuration | Polices préchargées | LCP mesuré (4G simulée) |
|---|---|---|
| Thème par défaut, sans réglage | 6 | 3,8 s |
| Après réduction à une police variable | 1 | 2,1 s |
Sur nos projets, retirer les préchargements superflus a systématiquement rapporté plus de gain que n’importe quelle optimisation d’image sur la même page.
En résumé
Le préchargement de polices n’est pas mauvais en soi : c’est son usage sans discernement qui pénalise le rendu. Une seule règle à retenir : une police critique préchargée, toutes les autres chargées normalement via la feuille de style. Vérifiez systématiquement l’attribut crossorigin, et mesurez toujours en conditions réseau dégradées avant de considérer le sujet clos.