# Un en-tête Link rel=preload posé par l’API REST pour devancer le rendu du front

> Ajouter un en-tête de préchargement à une réponse REST permet au navigateur de démarrer le chargement d'une police avant même que le front ne parse le JSON reçu.

- Auteur : WordPress Développement
- Publié le : 2022-10-15
- Mis à jour le : 2022-10-15
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/en-tete-link-rel-preload-api-rest-devancer-rendu/

## L’essentiel

- L'en-tête Link rel=preload peut être posé sur n'importe quelle réponse HTTP
- Le navigateur démarre le chargement sans attendre le parsing du JSON
- rest_post_dispatch reste le point d'accroche naturel pour cet en-tête

```
Link: <https://exemple.test/fonts/inter-variable.woff2>; rel=preload; as=font; crossorigin
```

Cet 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

> L'essentiel à retenir : L'en-tête Link rel=preload peut être posé sur n'importe quelle réponse HTTP ; Le navigateur démarre le chargement sans attendre le parsing du JSON ; rest_post_dispatch reste le point d'accroche naturel pour cet en-tête

```
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`.