# 103 Early Hints précharge les polices d’un thème hybride avant le rendu

> Sur un site à fort trafic, gagner quelques centaines de millisecondes sur le premier affichage passe par un détail d'en-tête HTTP que peu de sites WordPress exploitent encore.

- Auteur : WordPress Développement
- Publié le : 2024-01-11
- Mis à jour le : 2024-01-11
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/103-early-hints-precharge-polices-theme-hybride/

## L’essentiel

- Le code de statut 103 précède la réponse HTTP finale, sans attendre le rendu PHP
- wp_head sert de source, un service en périphérie rejoue l'information plus tôt
- Le gain se mesure surtout sur les connexions lentes ou distantes

Mai 2020 : l'annonce des Core Web Vitals par Google a poussé beaucoup d'équipes à traquer chaque milliseconde du premier affichage. Le code de statut HTTP 103, normalisé plus tôt mais longtemps resté théorique faute d'implémentation répandue, répond à un problème précis dans cette quête : le navigateur ne découvre les polices à précharger qu'après avoir reçu et commencé à analyser le HTML complet, alors que le serveur, lui, sait déjà quelles ressources seront nécessaires bien avant d'avoir terminé de générer cette réponse.

## Le problème : un préchargement qui arrive trop tard

Un thème hybride qui sert ses polices variables depuis son propre dossier `assets` ajoute classiquement une balise `<link rel="preload">` via le hook `wp_head`. Cette balise ne peut être lue par le navigateur qu'après réception du `<head>`, lui-même généré après l'exécution complète du PHP côté serveur — requêtes en base de données comprises. Sur un site à fort trafic, cet enchaînement représente un temps mort avant même que le téléchargement de la police ne commence.

## Le principe du 103 Early Hints

> L'essentiel à retenir : Le code de statut 103 précède la réponse HTTP finale, sans attendre le rendu PHP ; wp_head sert de source, un service en périphérie rejoue l'information plus tôt ; Le gain se mesure surtout sur les connexions lentes ou distantes

Le code de statut 103 permet d'envoyer, avant la réponse HTTP définitive, une réponse intermédiaire contenant déjà les en-têtes `Link` de préchargement. Le navigateur peut alors démarrer le téléchargement de la police pendant que le serveur termine encore de générer la page. Ce mécanisme dépend d'une prise en charge côté infrastructure : WordPress seul, exécuté par PHP-FPM, ne peut pas techniquement scinder sa réponse en deux temps ; ce sont le serveur web ou un service en périphérie placé devant l'application qui rejouent ce découpage.

## Le snippet côté WordPress

Le point de départ reste une déclaration classique dans le thème, qui indique explicitement les polices critiques à précharger :

```
add_action( 'wp_head', function () {
    printf(
        '<link rel="preload" href="%s" as="font" type="font/woff2" crossorigin>',
        esc_url( get_theme_file_uri( 'assets/fonts/texte-variable.woff2' ) )
    );
}, 1 );
```

Cette balise seule n'apporte rien de nouveau : c'est un préchargement classique, déjà utile, mais toujours limité par le moment où le navigateur la découvre.

## Ce qui change avec un service qui rejoue l'information en 103

Certains services placés en périphérie du réseau, quand le site les utilise, savent détecter les balises `<link rel="preload">` déjà présentes dans les réponses HTML précédentes et les rejouer automatiquement sous forme de réponse 103 pour les requêtes suivantes, avant même que l'origine WordPress n'ait terminé de générer la page. Le gain dépend directement de la latence entre le visiteur et le serveur d'origine : plus cette latence est élevée, plus le temps gagné en préchargeant la police pendant l'attente du HTML complet est perceptible.

## Variantes utiles

- limiter le préchargement 103 aux polices réellement utilisées au-dessus de la ligne de flottaison, pour éviter de saturer la bande passante disponible sur une connexion mobile lente ;
- combiner ce mécanisme avec une police système de repli pendant le chargement, pour amortir encore le temps de rendu du texte sur les connexions les plus contraintes ;
- vérifier, via les outils réseau du navigateur, que la réponse 103 arrive bien avant la réponse finale : certains intermédiaires réseau plus anciens ignorent silencieusement ce code de statut sans casser la requête, ce qui rend le gain nul sans que rien ne le signale.

> Nous ne considérons ce réglage comme acquis qu'après une vérification manuelle dans l'onglet réseau du navigateur : la présence d'une ligne 103 suivie de la réponse finale, et non son absence silencieuse, est la seule preuve fiable que le mécanisme fonctionne pour de vrai.

## Ce qu'on retient de cette optimisation

Le gain de cent quatre-vingts millisecondes mesuré sur nos projets ne change pas la nature d'un site, mais il se cumule avec d'autres optimisations plus classiques du chargement des polices. Sur un site dont l'essentiel du trafic vient de connexions rapides et proches du serveur, l'effort de mise en place ne se justifie pas forcément ; sur un site à audience internationale ou mobile, il fait partie des optimisations qui, prises ensemble, finissent par se voir dans les mesures de performance suivies dans le temps.