Chrome propone nuove API per aggiornamenti web più efficienti

Google continua a intervenire sulle fondamenta della piattaforma Web e stavolta il bersaglio è uno dei limiti storici di HTML: l’elaborazione strettamente sequenziale dei contenuti. Con la proposta chiamata Declarative Partial Updates, il team di Chrome introduce un insieme di API (Application Programming Interfaces) che permettono di aggiornare porzioni della pagina fuori ordine, senza affidarsi a pesanti manipolazioni DOM o a framework JavaScript complessi. L’obiettivo consiste nel ridurre latenza percepita, semplificare lo streaming HTML e rendere più efficiente il rendering progressivo delle applicazioni web.

La novità è arrivata attraverso il blog ufficiale di Chrome Developers ed è già disponibile in fase sperimentale a partire da Chrome 148, attivando il flag chrome://flags/#enable-experimental-web-platform-features.

HTML nasce come formato di documento, non come runtime applicativo. Quando una pagina attende dati lenti – una query SQL, una chiamata API, una generazione server side – il browser riceve spesso blocchi incompleti oppure JavaScript è incaricato di ricostruire il DOM (struttura della pagina) in seguito. Chrome prova ora a riportare parte di questa logica direttamente nella piattaforma.

Perché il rendering lineare crea ancora problemi

Il browser interpreta HTML dall’alto verso il basso. Sembra banale, ma questo comportamento influenza direttamente il modo in cui sono costruite le applicazioni web moderne.

Se una sezione della pagina dipende da dati ancora non disponibili, il server ha due possibilità: aspettare oppure inviare dei “segnaposto temporanei” che JavaScript sostituirà successivamente.

Entrambe le strade hanno limiti concreti. Aspettare rallenta il First Contentful Paint e peggiora la percezione di reattività, tanto che Google stessa penalizza (in termini di ranking e quindi di visibilità) le pagine che risultano lente a caricarsi.

Demandare tutto al client implica invece più JavaScript e più lavoro lato browser. Anche se molti framework hanno costruito intere architetture attorno a questo problema cercando di gestirlo nel miglior modo possibile.

Google sostiene che parte di questa complessità possa essere eliminata introducendo primitive native direttamente nel parser HTML: il browser riceve contenuti parziali e li colloca nella posizione corretta anche se arrivano più tardi rispetto alla struttura iniziale della pagina. È questa la filosofia alla base di Declarative Partial Updates.

Come funzionano i nuovi aggiornamenti dichiarativi

La proposta degli sviluppatori di Chrome introduce un sistema basato su <template> e nuove processing instructions HTML. Storicamente le processing instructions appartenevano al mondo XML; in HTML il parser le trattava come semplici commenti del tutto ignorati. Chrome ora cambia comportamento e permette di usarle come punti di aggancio dinamici.

Il meccanismo ruota attorno a marker come:

<?marker name="placeholder">

oppure:

<?start name="results">
<?end>

Successivamente il server può inviare:

<template for="placeholder">...contenuto...</template>

Quando il parser incontra il template associato, aggiorna automaticamente il nodo corretto nel documento della pagina web: la parte interessante è che l’ordine di arrivo non deve più coincidere con l’ordine finale della pagina.

Dietro le quinte il browser modifica il comportamento del parser HTML in fase di streaming. Eliminare i passaggi intermedi riduce allocazioni DOM inutili e limita il lavoro di tipico dei framework client side.

Le nuove API di streaming HTML

Chrome non si ferma alle processing instructions. La seconda parte della proposta introduce una famiglia di API per inserimento e streaming HTML.

Oggi il Web mette a disposizione strumenti separati come innerHTML, outerHTML, insertAdjacentHTML, createContextualFragment, setHTML e setHTMLUnsafe. Sebbene servano tutti a inserire o manipolare contenuti HTML, ciascuno funziona in modo diverso: cambiano i meccanismi di sanitizzazione del codice per prevenire vulnerabilità, il comportamento nell’esecuzione degli script JavaScript, il supporto a Trusted Types per aumentare la sicurezza contro gli attacchi XSS e le modalità con cui il contenuto viene aggiunto o sostituito nel documento.

La nuova proposta prova a uniformare il modello introducendo metodi come:

setHTML()
appendHTML()
prependHTML()
beforeHTML()
afterHTML()
replaceWithHTML()

Ogni API ha anche una controparte streaming:

streamHTML()
streamAppendHTML()
streamPrependHTML()
streamReplaceWithHTML()

Il browser può ricevere uno stream HTML progressivo senza attendere il payload completo. Fino a oggi molti sistemi erano costretti a simulare streaming tramite chunk manuali o addirittura vecchie tecniche come document.write().

Trusted Types, sanitizzazione e rischi reali

Presentando le nuove API Declarative Partial Updates, Google dedica molto spazio al tema sicurezza. Ogni API che inserisce HTML dinamico nel DOM apre immediatamente il problema Cross-Site Scripting (XSS), una vulnerabilità web che permette a un malintenzionato di iniettare script dannosi all’interno delle pagine web visualizzate dagli utenti.

Le nuove API puntano a uniformare il comportamento del browser: le versioni considerate sicure eseguono automaticamente la sanitizzazione del codice HTML, cioè rimuovono o bloccano contenuti potenzialmente pericolosi, mentre le varianti Unsafe richiedono maggiore attenzione da parte dello sviluppatore perché non applicano queste protezioni.

Il supporto a Trusted Types resta un elemento chiave: gestire in modo coerente le sorgenti HTML è essenziale per evitare vulnerabilità dovute all’iniezione accidentale di codice malevolo. Il rischio reale è che i team meno esperti scelgano le versioni Unsafe per comodità, reintroducendo problemi di sicurezza che i browser cercano di limitare da anni. Va comunque precisato che il problema non nasce con queste API: anche oggi innerHTML è spesso utilizzata in modo scorretto. La differenza è che Chrome sta cercando di introdurre un modello più chiaro, prevedibile e meno soggetto ad ambiguità.

Una direzione che cambia il rapporto tra browser e framework

La proposta di Chrome racconta qualcosa di più ampio rispetto a una semplice nuova API. Da tempo i browser osservano l’evoluzione dei framework JavaScript e cercano di incorporarne le idee migliori direttamente nella piattaforma. Il browser tenta di riappropriarsi di funzionalità che negli anni si erano spostate nei runtime JavaScript applicativi.

Non significa che React o Vue spariranno: però potrebbe ridursi la quantità di codice necessaria per ottenere rendering progressivo, aggiornamenti incrementali e streaming UI. Per chi sviluppa frontend complessi il vantaggio potenziale è notevole.

Resta da capire, a questo punto, quanto rapidamente queste API usciranno dalla fase sperimentale e soprattutto se Firefox e Safari decideranno di seguirne l’implementazione. Il Web moderno vive di interoperabilità: una funzione disponibile solo in Chromium e derivati (compresi Chrome ed Edge) rischia di rimanere confinata agli esperimenti.