Résumé

  • Le RFC 7540 a donné aux serveurs HTTP/2 le droit de promettre, puis d'envoyer, une ressource que le client pourrait demander. Le navigateur pouvait désactiver ou refuser cet envoi.
  • Le RFC 9113 conservait Server Push en juin 2022 et détaillait les risques d'une prédiction erronée. La notice de Chrome 106 a ensuite annoncé la suppression de la réception, du stockage en mémoire et de l'utilisation des flux poussés.

Une réponse avant la question

Une page HTML mentionne souvent des scripts et des feuilles de style. Le serveur qui prépare la page les connaît déjà. Pourquoi attendre que le navigateur découvre ces références et formule d'autres demandes ? Dans le HTTP/2 publié en 2015, Server Push permettait au serveur d'annoncer par PUSH_PROMISE une requête qu'il avait fabriquée pour le client, puis d'envoyer la réponse sur un autre flux. Une bonne anticipation pouvait faire gagner un aller-retour réseau.

La norme ne donnait pourtant pas carte blanche à l'expéditeur. La promesse devait être liée à une demande réelle du client, concerner une opération sûre et pouvant être mise en cache, et respecter l'autorité de l'origine. Le client pouvait déclarer SETTINGS_ENABLE_PUSH=0 ou rejeter un flux. Le serveur avait le droit de proposer un raccourci ; le navigateur gardait le droit de ne pas recevoir le colis.

Le pari demandait au serveur de connaître un état qu'il ne voyait qu'en partie. Le navigateur avait peut-être déjà le fichier en cache. La négociation du contenu pouvait choisir une autre variante. L'utilisateur pouvait quitter la page. Envoyer une ressource inutile occupait la connexion au moment où une réponse réellement demandée aurait pu passer. Accélérer un mauvais colis ralentit parfois la bonne livraison.

La révision nomme le coût

Le RFC 9113 de juin 2022 a gardé une section entière à Server Push. Il reprenait la promesse de rapidité pour les scripts ou styles anticipés, puis exposait le piège : cache, négociation et comportement de l'utilisateur rendent la prévision difficile. Des octets envoyés pour rien peuvent entrer en concurrence avec des réponses plus importantes. La norme conservait aussi le réglage permettant au client de refuser le mécanisme.

Une norme peut décrire un échange sans assurer son intérêt économique pour celui qui l'implémente. Recevoir un flux poussé demande du code, de la mémoire, une coordination avec le cache et des choix de priorité. Quand les gains deviennent incertains, le destin de cette fonction se joue dans les logiciels distribués aux lecteurs, pas dans la présence de son titre dans la table des matières d'un RFC.

Dans son explication d'août 2022, Chrome annonçait une désactivation par défaut dans la version 106. L'équipe évoquait des bénéfices difficiles à obtenir et des résultats mêlés, parfois négatifs. La notice des suppressions de Chrome 106 précisait l'acte : le navigateur n'était plus capable de recevoir, garder en mémoire et exploiter ces flux. HTTP/2 continuait ; son option de livraison anticipée avait perdu cette boîte aux lettres.

L'indice remplace le colis

Chrome proposait notamment 103 Early Hints et le préchargement. Son article de retrait décrivait Early Hints comme un signal permettant au navigateur de décider lui-même s'il devait demander la ressource, notamment en fonction de son cache. L'histoire de ce signal possède ses propres règles. Ici, la bascule décisive est plus concrète : le serveur ne pouvait plus déposer dans Chrome une réponse que le navigateur n'avait pas sollicitée.

Server Push a eu une vie longue sur le papier et plus courte à cette extrémité du réseau. Le RFC de 2015 autorisait la spéculation, celui de 2022 en détaillait les dangers, puis Chrome retirait le code de réception. Les trois actes montrent à quel endroit une optimisation standardisée cesse d'être un service rendu au lecteur.