Out-of-order HTML streaming é a técnica que permite ao usuário ver e interagir com uma página antes do carregamento completo, e agora deixa de ser exclusividade de frameworks JavaScript para virar recurso nativo do navegador. O Chrome 150 e o Edge 150 já trazem os recursos declarativos, segundo o anúncio coberto pelo InfoQ, enquanto WebKit e Mozilla sinalizaram apoio à Proposta declarative-partial-updates no WICG (GitHub) (github.com).
Sob a proposta, o próprio navegador preenche placeholders à medida que os dados chegam, seja por HTML declarativo ou por APIs JavaScript correspondentes. A meta é acabar com o cenário em que uma parte lenta da página trava o carregamento inteiro.
Como funciona o streaming declarativo com template
A proposta declarativa introduz o streaming fora de ordem usando o elemento padrão <template> com um novo atributo for. O desenvolvedor declara pontos únicos de inserção com <?marker name="profile">, ou envolve conteúdo temporário de fallback com <?start name="profile">Carregando perfil...<?end>.
Quando o servidor envia mais tarde um <template for="profile"> correspondente, o parser de HTML casa o identificador, remove os marcadores <?start> e <?end> junto com os nós de fallback entre eles, e insere o conteúdo do template naquela posição do DOM.
Info: os marcadores declarativos (<template for> e as processing instructions) já foram incorporados ao WHATWG HTML Living Standard, com suporte inicial no Chrome e Edge 150.
# publicidade
Atualizações múltiplas no mesmo ponto
Developers podem incluir processing instructions dentro dos templates para permitir múltiplas atualizações no mesmo destino. Um exemplo clássico: uma lista <ul id="results"> começa com "Loading…" entre os marcadores, e templates subsequentes na resposta HTTP vão adicionando itens <li> um a um. Após o processamento, o HTML final contém apenas os resultados reais e o marcador residual.
Proteção contra injeção entre componentes
Para evitar ataques de injeção cruzada entre componentes, um <template for> só pode atualizar processing instructions localizadas dentro do seu elemento pai imediato, ou seja, seus irmãos diretos e descendentes. A exceção explícita: um template colocado diretamente sob <body> recebe escopo global de documento, permitindo atualizações adiadas que alcançam elementos no <head> ou em contêineres estruturais aninhados.
Atenção: sem essa restrição de escopo, markup não confiável poderia sequestrar formulários sensíveis ou alvos de navegação em outras partes do documento.
APIs javascript e integração com fetch
A iniciativa combina as primitivas de markup com uma suíte unificada de métodos estáticos e de streaming para inserção no DOM. A especificação define uma matriz previsível de operações: setHTML, replaceWithHTML, beforeHTML, prependHTML, appendHTML e afterHTML, além das versões de streaming (streamHTML, streamAppendHTML e outras) e variantes *Unsafe.
Invocar streamHTMLUnsafe(), por exemplo, retorna um WritableStream que canaliza incrementalmente os chunks recebidos para um parser interno de fragmentos HTML. A Fetch API complementa o fluxo com o helper Response.textStream() na MDN Web Docs (developer.mozilla.org), que chega na versão 151 do Chrome.
const feedContainer = document.querySelector("#feed-container");
const response = await fetch("/api/feed-stream");
await response.textStream().pipeTo(
feedContainer.streamHTMLUnsafe({ runScripts: false })
);Na prática, um fragmento dinâmico de HTML pode ser canalizado direto para o contêiner de destino, sem framework no meio. Para quem já mantém interfaces com renderização progressiva, isso reduz dependência de soluções proprietárias.
Dica: ao adotar os métodos *Unsafe, mantenha runScripts: false como padrão para evitar execução de scripts vindos do stream.
Por que os navegadores estão absorvendo esse padrão?
A técnica nasceu em 2009 com o BigPipe: pipelining web pages for high performance (Meta... (engineering.fb.com)-web-pages-for-high-performance/" rel="nofollow noopener noreferrer" target="_blank">BigPipe do Facebook e depois foi popularizada por frameworks como React, com o streaming via Suspense, e Next.js. As implementações diferem, mas o objetivo é comum: impedir que uma parte lenta da página bloqueie todo o resto.
Cada framework resolveu o problema do seu jeito ao longo dos anos. Como isso afeta quem desenvolve hoje? Ao internalizar a entrega fora de ordem na engine do navegador, a proposta padroniza algo que antes exigia soluções divergentes e código de cliente mais pesado.
No lado da padronização, as primitivas declarativas entraram no WHATWG HTML Living Standard, enquanto os métodos JavaScript de streaming no DOM seguem um processo separado de padronização. O WebKit publicou posição positiva sobre o padrão, e a Mozilla sinalizou interesse receptivo.
O que muda para quem desenvolve
Na avaliação do Mercado de TI, o movimento indica um caminho conhecido: padrões consolidados na camada de framework tendem a migrar para a plataforma, como já aconteceu com módulos ES e fetch. Para times que mantêm aplicações com React ou Next.js, o ganho imediato não é reescrever nada, mas acompanhar a convergência de APIs que pode simplificar o bundle no médio prazo.
A primeira frase vale como resumo: o streaming fora de ordem vira capacidade nativa do navegador, com suporte declarativo no Chrome e Edge 150 e textStream() na versão 151. O próximo passo prático é acompanhar o repositório da proposta no WICG e observar quando Safari e Firefox transformam a sinalização em lançamento.
Fonte: Infoq
