# HTTP/3 et Early Hints 103 : ce que ça change pour WordPress

> QUIC élimine le blocage de tête de ligne, les Early Hints 103 laissent le navigateur précharger avant même la réponse complète. Comprendre ces deux technologies et leur support réel côté WordPress.

- Auteur : Clément Hadrot
- Publié le : 2024-10-07
- Mis à jour le : 2024-10-07
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/http3-early-hints-103-wordpress/

## L’essentiel

- HTTP/3 s'appuie sur QUIC, un transport en UDP qui évite le blocage de tête de ligne de TCP
- Les Early Hints 103 permettent de démarrer le préchargement des ressources avant la réponse finale
- Le support dépend presque entièrement du CDN ou du reverse proxy, rarement de WordPress lui-même

Deux sigles reviennent de plus en plus dans les discussions sur la performance web : HTTP/3 et Early Hints. Contrairement à des optimisations applicatives comme la mise en cache ou la compression d'images, ces deux technologies se situent au niveau du protocole de transport et de la couche HTTP elle-même, largement en dehors du contrôle direct de WordPress. Comprendre ce qu'elles font, et surtout ce qu'elles ne font pas, évite d'attendre des miracles d'une simple case à cocher chez l'hébergeur.

Cet article ne revient pas sur HTTP/2, déjà largement couvert ailleurs, et se concentre sur ce que ces deux évolutions récentes apportent concrètement à un site WordPress.

## HTTP/3 et QUIC : ce qui change sous le capot

HTTP/3 repose sur QUIC, un protocole de transport développé initialement par Google, désormais normalisé par l'IETF, qui fonctionne au-dessus d'UDP plutôt que de TCP. Le changement le plus important concerne le blocage de tête de ligne (head-of-line blocking) : en HTTP/2 sur TCP, la perte d'un seul paquet bloque toutes les autres requêtes multiplexées sur la même connexion en attendant sa retransmission. QUIC traite chaque flux indépendamment, donc la perte d'un paquet lié à une ressource n'affecte pas le téléchargement des autres.

Deuxième différence notable : QUIC intègre TLS 1.3 directement dans son établissement de connexion, ce qui réduit le nombre d'allers-retours nécessaires avant le premier octet de données utiles, particulièrement sensible sur les connexions mobiles à latence élevée. Pour une reprise de connexion vers un serveur déjà visité récemment, QUIC peut envoyer des données applicatives dès le premier paquet, sans round-trip supplémentaire de négociation.

## Early Hints 103 : préchargement avant la réponse complète

> L'essentiel à retenir : HTTP/3 s'appuie sur QUIC, un transport en UDP qui évite le blocage de tête de ligne de TCP ; Les Early Hints 103 permettent de démarrer le préchargement des ressources avant la réponse finale ; Le support dépend presque entièrement du CDN ou du reverse proxy, rarement de WordPress lui-même

Le code de statut HTTP 103 Early Hints permet à un serveur d'envoyer une réponse préliminaire contenant des en-têtes `Link` de préchargement, avant même d'avoir terminé de générer la réponse finale (le code 200). Le navigateur peut ainsi commencer à télécharger la feuille de style principale ou une police critique pendant que WordPress termine de générer le HTML, plutôt que d'attendre la réponse complète pour découvrir ces ressources dans le `<head>`.

```
HTTP/1.1 103 Early Hints
Link: </wp-content/themes/mon-theme/style.css>; rel=preload; as=style
Link: </wp-content/uploads/fonts/inter-var.woff2>; rel=preload; as=font; crossorigin

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
...
```

Sur un site où le temps de génération serveur (TTFB) dépasse 200 ou 300 ms, l'effet des Early Hints est le plus perceptible, puisque le navigateur gagne exactement ce temps d'avance sur le téléchargement des ressources critiques.

## Ce que WordPress fait, et ce qu'il ne fait pas

WordPress lui-même n'émet pas nativement de réponse 103 Early Hints : cette fonctionnalité doit être portée par le serveur web ou le CDN placé devant. Cloudflare propose par exemple un support natif des Early Hints qui s'appuie sur les en-têtes de préchargement déjà présents dans le HTML généré par WordPress, sans modification du cœur.

Côté HTTP/3, le support dépend entièrement de la couche réseau : Nginx à partir de la version 1.25 avec le module QUIC compilé, ou directement au niveau du CDN pour les hébergeurs qui en utilisent un devant leurs serveurs d'origine. WordPress répond de la même façon quel que soit le protocole de transport utilisé pour l'acheminer jusqu'au navigateur ; il n'y a rien à configurer dans WordPress lui-même pour activer HTTP/3.

## Gains à attendre, sans exagération

- Sur un réseau mobile de qualité moyenne avec pertes de paquets, HTTP/3 apporte un gain mesurable et régulier, souvent entre 5 et 15 % sur le temps de chargement complet.
- Sur une connexion fibre stable, l'écart avec HTTP/2 est souvent difficile à distinguer, le blocage de tête de ligne étant rarement le facteur limitant dans ces conditions.
- Les Early Hints apportent un gain proportionnel au TTFB du site : plus la génération WordPress est lente, plus l'avance prise par le préchargement est significative.

## Notion à retenir

HTTP/3 et Early Hints sont deux optimisations complémentaires mais indépendantes, situées en dehors du périmètre direct de WordPress. Elles se configurent au niveau du serveur web, du reverse proxy ou du CDN, et leur effet dépend fortement des conditions réseau des visiteurs et du temps de génération propre du site. Elles méritent d'être activées dès que l'infrastructure le permet, sans coût de compatibilité côté WordPress, mais ne dispensent en rien d'un travail sur le TTFB applicatif lui-même.
