Chrome streame désormais le HTML dans le désordre par défaut. Safari et Firefox sont tous les deux partants.

Depuis le 30 juin, tous les utilisateurs de Chrome sur ordinateur, Android et ChromeOS disposent d’une nouvelle capacité HTML activée sans flag, sans opt-in, sans annonce que la plupart d’entre eux verront un jour. Elle permet à une page d’afficher immédiatement tout ce qui est prêt, puis de compléter la partie lente plus tard, à l’endroit exact où elle doit apparaître, sans une seule ligne de JavaScript. Ce qui compte vraiment n’est pas la fonctionnalité elle-même. C’est que Safari et Firefox ont tous les deux signalé leur intention de la supporter aussi — c’est ce détail qui décide si une astuce de navigateur devient une vraie capacité de la plateforme web.

Le problème que ça règle concrètement

Le HTML s’est toujours chargé de haut en bas, dans l’ordre où il a été écrit. Ça fonctionne tant qu’aucune section n’est lente : une galerie produit qui interroge une API non mise en cache, un bloc de commentaires qui attend une requête base de données, n’importe quoi que le serveur ne peut pas renvoyer instantanément. Dans l’ancien modèle, ce bloc lent reste planté dans le flux du document et bloque l’affichage de tout ce qui vient après, même du contenu qui aurait pu s’afficher une seconde après le début du chargement.

Les développeurs contournent ça depuis des années avec du JavaScript : récupérer les données lentes à part, puis les injecter dans le DOM une fois arrivées. Ça marche, mais ça veut dire écrire à la main la logique de récupération, la manipulation du DOM et les états de chargement pour une idée qui, au fond, est très simple : afficher ce qui est prêt, puis rapiécer ce qui ne l’était pas.

Ce qui est réellement livré

L’annonce officielle de Chrome, publiée le 19 mai 2026, qui détaille les deux volets de l’API décrits ci-dessous.

L’équipe d’ingénierie Chrome appelle cette fonctionnalité Declarative Partial Updates (“mises à jour partielles déclaratives”), livrée en deux volets.

Le premier permet de streamer du HTML dans le désordre sans aucun JavaScript. On dépose un marqueur à l’endroit où le contenu doit finir par apparaître, écrit comme une instruction de traitement : <?marker name="gallery">. Plus loin dans le même flux HTML, une fois le contenu lent prêt, on envoie un <template for="gallery"> contenant le vrai balisage, et le navigateur l’insère à sa place. Il existe aussi une variante avec placeholder, <?start name="gallery">Chargement…<?end>, qui affiche un contenu intermédiaire jusqu’à l’arrivée du vrai template. Rien de tout cela ne nécessite de balise script. Le navigateur lit les marqueurs et les templates au fil de leur arrivée dans le flux et fait l’insertion lui-même.

Le second volet est un jeu de nouvelles méthodes JavaScript pour les cas qui ont vraiment besoin d’un script : setHTML(), appendHTML(), prependHTML(), beforeHTML(), afterHTML(), replaceWithHTML(), plus leurs versions streaming (streamHTML(), streamAppendHTML(), etc.) pour du contenu qui arrive progressivement plutôt que d’un bloc. Chacune a une variante *Unsafe qui saute l’échappement HTML, pour les cas où le développeur a déjà assaini le contenu et veut éviter le coût de performance d’un ré-échappement.

C’est déjà en ligne, et c’est le détail qui compte

Les notes de version officielles de Chrome 150, confirmant la date stable du 30 juin 2026 et listant le streaming hors-ordre parmi les changements DOM/HTML livrés.

La fonctionnalité est allée vite, à l’échelle des calendriers habituels des standards navigateur. Elle a atteint les tests développeurs sous flag dans Chrome 148, en mai. Dans Chrome 150, passé stable le 30 juin, elle était activée pour tout le monde, sans flag. Les notes de version officielles de Chrome 150 le listent directement : support de <template for> et des plages d’instructions de traitement (<?marker>, <?start>, <?end>) qui « mettent à jour des parties existantes du document sans JS ».

Ce rythme s’est accompagné d’un vrai travail de test, pas juste d’un basculement discret. L’équipe Chromium a fait tourner le changement en Finch trial à 50% sur le canal beta avant de le promouvoir en stable, et il est couvert par la suite de tests web platform partagée que les fabricants de navigateurs utilisent pour vérifier la compatibilité entre moteurs. Un vrai risque a reçu une attention spécifique dans ce processus : les instructions de traitement sont un coin ancien et globalement inutilisé du HTML, et les réutiliser pour un nouvel usage risquait d’entrer en collision avec le rare contenu legacy qui s’appuyait déjà sur cette syntaxe. Les parades livrées : interdiction des noms d’instructions et des caractères spécifiques dont on a constaté qu’ils étaient utilisés par du contenu existant.

Ce qui compte plus que la date de sortie

Un seul navigateur qui ajoute une fonctionnalité est routinier et, en soi, n’est pas une nouvelle. Ce qui distingue celle-ci, c’est qui d’autre est derrière. WebKit, le moteur de Safari, a affirmé son soutien au streaming hors-ordre. L’équipe Gecko de Mozilla a elle aussi une position de standard ouverte et formulée favorablement, sous la forme d’un « support proposé » plutôt qu’un engagement ferme, mais sans le rejet qui coule habituellement la plupart des propositions venues de Chromium avant qu’elles n’aillent nulle part. Trois moteurs de navigateur indépendants qui convergent sur le même mécanisme, c’est ce qui transforme une astuce Chrome en une pièce durable de la plateforme web — la différence entre une capacité sur laquelle les développeurs peuvent construire pour la décennie qui vient et une capacité tranquillement abandonnée le jour où l’équipe Chrome passe à l’idée suivante.

À qui ça profite vraiment

La réserve honnête, celle qu’il est le plus facile de sauter dans une annonce de fonctionnalité : ça n’aide que les sites où le serveur peut terminer de générer certaines sections avant d’autres. Un site classique rendu côté serveur, du genre où un framework récupère chaque donnée en amont puis rend une page complète d’un bloc, n’a rien à streamer en retard. Il n’y a pas de bloc lent isolé du reste, puisque tout a déjà été récupéré avant même que le HTML ne commence à être généré.

Le bénéfice se concentre sur les architectures orientées composant : React Server Components, le SSR en streaming façon Next.js, ou tout dispositif où des sections de page indépendantes peuvent se résoudre chacune à son propre rythme. Les exemples officiels de Chrome vont dans le même sens : pages en architecture d’îlots où un widget est plus lent que le reste, contenu qui dépend de la fin d’un appel base de données, priorisation du HTML au-dessus de la ligne de flottaison pendant qu’un bloc secondaire traîne derrière, mises à jour de navigation façon single-page-app sans embarquer de framework de routage, insertion d’éléments partagés comme un pied de page après que le contenu principal a déjà été rendu.

Ce qu’il faut en retenir

Rien dans tout ça n’exige une décision immédiate. Si votre stack génère déjà du HTML en morceaux indépendants qui se résolvent de façon asynchrone, ça vaut le coup de tester dès maintenant, la syntaxe est assez légère pour un prototype en une après-midi et le repli pour les navigateurs sans support consiste simplement à ne pas s’en servir. Si votre stack est un site classique rendu côté serveur qui assemble une page à partir d’une seule récupération de données, il n’y a aucune urgence : la fonctionnalité n’a rien à offrir à cette architecture, et ça ne changera pas tant que l’architecture elle-même ne changera pas.

FAQ

Faut-il activer un flag pour utiliser ça dans Chrome ? Non. C’est activé par défaut depuis Chrome 150, passé sur le canal stable le 30 juin 2026. La version sous flag n’était nécessaire que pendant la phase de test développeurs de Chrome 148.

Est-ce que ça marche déjà dans Safari et Firefox ? Pas encore sous forme stable et livrée, mais les deux moteurs ont pris des positions de standard favorables. WebKit a affirmé son soutien au streaming hors-ordre, et l’équipe Gecko de Mozilla a une position ouverte et favorable. À traiter comme une capacité avec un vrai momentum multi-navigateur, pas comme une fonctionnalité Chrome-only, mais vérifiez le support réel de chaque moteur avant d’en dépendre en production.

Faut-il du JavaScript pour s’en servir ? Pas pour le cas de base. Le duo <?marker>/<template for> pour le streaming hors-ordre fonctionne en HTML pur. Le JavaScript n’est requis que pour les nouvelles méthodes d’insertion dynamique, comme setHTML() ou streamAppendHTML(), qui couvrent des cas comme la mise à jour de contenu après le chargement initial sans navigation complète.

Est-ce que ça va remplacer des frameworks comme React ou htmx pour ce genre d’usage ? Pas immédiatement, et pas entièrement. Ça remplace une partie de la plomberie manuelle que les développeurs écrivent aujourd’hui à la main ou délèguent à une bibliothèque, mais les frameworks ajoutent de la récupération de données, de la gestion d’état et des modèles de composants que cette fonctionnalité ne cherche pas à résoudre. C’est une brique de plateforme sur laquelle les frameworks peuvent construire, pas un remplacement de framework.

Y a-t-il un vrai gain de performance, ou c’est surtout une fonctionnalité de confort pour les développeurs ? Les deux. Le confort est réel : plus besoin d’écrire à la main la logique fetch-puis-injection en JavaScript pour le cas de base. Le gain de performance est réel aussi mais dépend de l’architecture : il n’aide que quand une page a de vraies sections indépendantes qui se résolvent à des vitesses différentes, ce qui est courant dans les frameworks orientés composant et globalement absent du rendu serveur classique à récupération unique.