Link: <https://exemple.test/fonts/inter-variable.woff2>; rel=preload; as=font; crossoriginCet en-tête, habituellement posé dans le HTML d’une page classique, fonctionne tout aussi bien sur une réponse d’API REST, alors même qu’aucun document HTML n’accompagne cette réponse. Le navigateur qui reçoit cet en-tête, quel que soit le type de contenu de la réponse, commence à télécharger la ressource indiquée sans attendre d’avoir terminé de traiter le corps de la réponse elle-même.
Étape 1 : comprendre pourquoi ça marche même sans HTML
Le préchargement via l’en-tête Link ne dépend pas du contenu de la réponse, mais uniquement des en-têtes HTTP transmis par le serveur. Un front headless qui effectue une requête fetch() vers l’API REST reçoit cette réponse dans le cadre normal du cycle réseau du navigateur, et celui-ci applique la directive de préchargement dès la réception des en-têtes, bien avant que le JavaScript du front n’ait eu le temps de parser le JSON reçu ni de décider quelle police charger.
Étape 2 : ajouter l’en-tête depuis un contrôleur REST
add_filter( 'rest_post_dispatch', function( WP_REST_Response $response, $server, $request ) {
if ( 0 !== strpos( $request->get_route(), '/wp/v2/posts' ) ) {
return $response;
}
$response->header(
'Link',
'<https://exemple.test/fonts/inter-variable.woff2>; rel=preload; as=font; crossorigin'
);
return $response;
}, 10, 3 );
Le filtre rest_post_dispatch s’exécute après le traitement complet du contrôleur, sur la réponse déjà construite, ce qui en fait le point d’accroche naturel pour ajouter un en-tête transversal sans toucher au code métier de chaque route. La condition sur get_route() permet de limiter l’ajout aux routes concernées par le premier rendu du front, plutôt que de l’appliquer indistinctement à toutes les réponses de l’API.
Étape 3 : vérifier l’effet côté navigateur
Dans les outils de développement d’un navigateur, l’onglet réseau permet de confirmer que la ressource préchargée démarre son téléchargement dès la réception de la réponse d’API, plutôt qu’après l’exécution du code JavaScript qui, normalement, l’aurait déclenché en analysant le résultat de la requête. Sur une police variable de taille conséquente, ce décalage temporel se traduit directement par un texte visible plus tôt, avant même que le reste de l’interface ne soit prêt à s’afficher.
Étape 4 : éviter les faux positifs de préchargement
- Ne précharger qu’une ressource réellement utilisée sur la vue concernée par cette requête précise
- Éviter d’appliquer cet en-tête à des routes appelées dans des contextes où la ressource ne sera jamais utilisée (un appel d’arrière-plan, une synchronisation périodique)
- Surveiller la console du navigateur, qui avertit explicitement quand une ressource préchargée n’est finalement pas utilisée dans les secondes suivantes
Étape 5 : ne pas se limiter aux polices
Le même mécanisme fonctionne pour toute ressource préchargeable au sens du navigateur : une image critique, une feuille de style, ou un script différé mais prioritaire. Le choix de la valeur as dans l’en-tête doit alors correspondre précisément au type de ressource visée, sous peine que le navigateur ignore silencieusement la directive plutôt que de précharger la ressource attendue.
En résumé
Poser un en-tête Link rel=preload sur une réponse d’API REST tire parti d’un mécanisme du navigateur qui ne dépend en rien du contenu de la réponse, uniquement de ses en-têtes. Sur un front headless dont le premier rendu dépend d’une police ou d’une image critique, cette technique permet de démarrer le chargement de cette ressource plus tôt que ce que le JavaScript du front aurait pu faire seul, pour un coût d’implémentation limité à quelques lignes accrochées au filtre rest_post_dispatch.
