# HTTP/2 Server Push abandonné : ce qui le remplace pour accélérer WordPress

> Le Server Push HTTP/2 a été retiré des navigateurs faute de gains réels. Pourquoi, et comment le preload ciblé le remplace efficacement sur un thème WordPress.

- Auteur : Clément Hadrot
- Publié le : 2020-11-04
- Mis à jour le : 2020-11-04
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/http2-server-push-abandonne-remplacement/

## L’essentiel

- Chrome a retiré le Server Push en 2020 faute de bénéfice net mesuré
- Le Server Push pousse des ressources même si le navigateur les a déjà en cache
- Le preload laisse le navigateur décider, sans ce gaspillage

Il y a quelques années encore, le Server Push HTTP/2 était présenté comme la solution miracle pour accélérer le chargement d'un site : le serveur pouvait envoyer au navigateur des ressources critiques, comme une feuille de style ou une police, avant même que celui-ci ne les demande. Sur le papier, l'idée semblait imparable. Dans la pratique, elle s'est révélée décevante, au point que les navigateurs commencent à la retirer purement et simplement.

Pour un site WordPress qui cherchait à en tirer parti via une configuration nginx dédiée, ce changement impose de revoir la stratégie de chargement des ressources critiques, avec une alternative plus simple et déjà largement supportée : le préchargement ciblé.

## Pourquoi le Server Push a déçu

Le problème central du Server Push tient à son fonctionnement aveugle : le serveur pousse des ressources selon une configuration statique, sans savoir si le navigateur les possède déjà en cache. Un visiteur qui revient sur le site reçoit alors des ressources qu'il n'a pas demandées et qu'il a peut-être déjà en local, gaspillant de la bande passante et retardant potentiellement l'arrivée du HTML principal, qui doit partager la même connexion.

Des études menées par plusieurs équipes de navigateurs, dont celle de Chrome, ont montré que dans un nombre significatif de cas réels, le Server Push n'apportait aucun gain de temps de chargement perceptible, et pouvait même le dégrader légèrement à cause de cette consommation de bande passante superflue. Ce constat a conduit Chrome à annoncer puis effectuer le retrait du support du Server Push en 2020, suivi par d'autres navigateurs.

## La différence fondamentale avec le preload

Le préchargement, exprimé via une balise `<link rel="preload">` ou un en-tête HTTP `Link`, fonctionne à l'inverse : c'est le navigateur qui décide s'il doit ou non télécharger la ressource indiquée, en tenant compte de son cache local. Le serveur ne fait qu'indiquer une intention, sans forcer l'envoi.

> L'essentiel à retenir : Chrome a retiré le Server Push en 2020 faute de bénéfice net mesuré ; Le Server Push pousse des ressources même si le navigateur les a déjà en cache ; Le preload laisse le navigateur décider, sans ce gaspillage

## Mettre en place le preload sur un thème WordPress

Sur ce projet, la police principale du thème et la feuille de style critique ont été identifiées comme les deux ressources qui gagnaient le plus à être préchargées. L'ajout s'est fait via le hook `wp_head`, en évitant toute extension supplémentaire :

```
function theme_preload_ressources_critiques() {
    echo '<link rel="preload" href="' . get_template_directory_uri() . '/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>' . "\n";
    echo '<link rel="preload" href="' . get_template_directory_uri() . '/style-critique.css" as="style">' . "\n";
}
add_action( 'wp_head', 'theme_preload_ressources_critiques', 1 );
```

Un point à ne pas négliger : l'attribut `as` doit correspondre exactement au type de ressource, sous peine de voir Chrome émettre un avertissement dans la console et ignorer partiellement le préchargement. Pour les polices, l'attribut `crossorigin` est également requis, même sur un domaine identique, faute de quoi la ressource est téléchargée deux fois.

## Ce qu'il ne faut pas précharger

Le préchargement n'est pas gratuit : chaque ressource marquée `preload` entre en concurrence avec les autres téléchargements de la page pour la bande passante disponible. Précharger trop de ressources, ou des ressources qui ne sont pas réellement utilisées immédiatement, peut retarder l'affichage du contenu principal. Sur ce projet, seules deux ressources ont été retenues après plusieurs essais, les tentatives de précharger des images de fond en plus ayant légèrement dégradé le First Contentful Paint mesuré avec Lighthouse.

- Précharger uniquement ce qui est utilisé sur la quasi-totalité des pages du site.
- Éviter de précharger des scripts JavaScript non critiques, qui bloquent inutilement d'autres téléchargements.
- Revalider régulièrement la liste, un thème évolue et une ressource préchargée peut devenir obsolète.

## En résumé

Le Server Push HTTP/2 restera comme un exemple d'idée séduisante sur le papier mais inefficace en conditions réelles, faute de tenir compte du cache navigateur. Le préchargement ciblé, plus simple à mettre en œuvre et déjà bien supporté, offre un contrôle plus fin et sans les effets de bord qui ont conduit à l'abandon du Server Push par les principaux navigateurs.