Un client m’a envoyé un rapport PageSpeed avec la mention « Preload key requests » soulignée en rouge, persuadé que son thème WordPress s’en occupait tout seul. Ce n’est pas le cas, et ça surprend souvent les développeurs qui découvrent WordPress après avoir travaillé sur des stacks JS où le bundler génère ces balises automatiquement.
WordPress ajoute effectivement des indices de ressources (resource hints) à certains endroits, mais son intervention s’arrête à deux des quatre types existants. Comprendre exactement ce que le cœur fait, et ce qu’il laisse de côté, évite de dupliquer des balises ou d’en oublier d’importantes.
Les quatre types d’indices de ressources
La spécification W3C Resource Hints définit quatre relations utilisables dans une balise <link> : dns-prefetch (résolution DNS anticipée), preconnect (résolution DNS + poignée de main TCP/TLS anticipée), prefetch (récupération basse priorité d’une ressource pour une navigation future probable) et preload (récupération haute priorité d’une ressource nécessaire à la page courante).
Ce sont des optimisations très différentes dans leur portée : preconnect prépare une connexion vers un domaine tiers, preload accélère le chargement d’un fichier précis déjà connu comme critique.
Ce que le cœur de WordPress ajoute réellement
La fonction responsable s’appelle wp_resource_hints(), accrochée au hook wp_head via wp_common_wp_head lui-même dans wp-includes/default-filters.php. Elle traite deux relations seulement :
dns-prefetchverss.w.org(les serveurs de WordPress.org, utilisés pour certaines ressources statiques)prefetchpour la pagination, quand le thème déclare le support de la fonctionnalité et que des liens de pagination existent
C’est tout. Aucun preconnect automatique n’est généré vers Google Fonts, un CDN d’images ou une API tierce. Aucun preload n’est ajouté pour la feuille de style principale, la police de caractères ou l’image d’en-tête, même si ces ressources sont systématiquement nécessaires au premier rendu.
Personnaliser les indices avec le filtre wp_resource_hints
Le filtre associé permet d’ajouter ou retirer des URL par type de relation :
add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
if ( 'preconnect' === $relation_type ) {
$urls[] = array(
'href' => 'https://fonts.gstatic.com',
'crossorigin',
);
}
return $urls;
}, 10, 2 );Notez la syntaxe particulière : pour preconnect avec l’attribut crossorigin, l’URL doit être un tableau associatif contenant à la fois href et l’attribut booléen, sinon WordPress affichera une simple chaîne sans l’attribut nécessaire au bon fonctionnement de la préconnexion vers un domaine de polices.
Ajouter un preload ciblé pour une ressource critique
Pour le preload, il n’existe pas de filtre dédié équivalent : il faut accrocher directement une balise sur wp_head, idéalement avec une priorité basse pour qu’elle sorte tôt dans le <head> :
add_action( 'wp_head', function() {
if ( is_front_page() ) {
printf(
'<link rel="preload" href="%s" as="image" fetchpriority="high">',
esc_url( get_theme_file_uri( 'assets/hero.webp' ) )
);
}
}, 1 );Le paramètre as est obligatoire : sans lui, le navigateur ignore silencieusement le preload ou le télécharge deux fois avec la mauvaise priorité. Sur nos projets, oublier as="font" avec crossorigin pour une police auto-hébergée est l’erreur la plus fréquente que je corrige en audit.
Le piège du surdosage
Une règle qui m’a évité bien des régressions : jamais plus de deux ou trois preloads par page. Chacun consomme de la bande passante prioritaire dès le début du chargement, et un preload de trop retarde justement la ressource qu’on voulait accélérer.
J’ai vu un site ajouter un preload sur chaque police de caractères utilisée (quatre graisses différentes) plus un preload sur la feuille de style, plus un sur l’image d’en-tête. Résultat mesuré au LCP : dégradation de 400 millisecondes, car le navigateur devait arbitrer entre cinq requêtes prioritaires simultanées au lieu d’une hiérarchie claire. Après réduction à un seul preload (la police du texte principal), le LCP est redescendu sous la seconde sur ce projet.
En résumé
WordPress ne préconnecte ni ne précharge rien pour vous en dehors de deux cas très spécifiques et internes à WordPress.org. Chaque preconnect vers un domaine tiers et chaque preload de ressource critique doit être ajouté à la main, mesuré, puis limité au strict nécessaire : la performance se dégrade aussi vite qu’elle s’améliore si on abuse de ces indices.
